3 ms·

You don't think go build, go fmt, etc. are great? I agree there are deficiencies, but a lot of my day to day (admittedly in emacs) is pretty great.

by boulos 11y ago

JBReefer 11y ago
Those are nice, but "great tooling" is Visual Studio or better, at a minimum.
- KirinDave 11y ago
  Not all languages with VS support or even VSC support have "great tooling." It's a very complicated set of balances and acceptance criterion.
- KirinDave 11y ago
  Not all languages with VS support or even VSC support have "great tooling." It's a very complicated set of balances and acceptance criterion.
- KirinDave 11y ago
  Not all languages with VS support or even VSC support have "great tooling." It's a very complicated set of balances and acceptance criterion.
KirinDave 11y ago
The compiler is very fast, and in absence of interactive development that's good. The cross compilation is also a thing I guess? I just use docker anyways. But no... I mean... I can get a lot of editors to do a better job of formatting. Other languages I use offer true interactive development. And go build requires a Zigguraut Of Filesystem around it to function properly. Go get provides no realistic versioning other than "this is what I grabbed RIGHT NOW and I hope you don't need bugfixes because good luck with figuring out the hash I got." The lack of reproducible builds and better tooling for versioning is a pretty damning stroke against the ecosystem, because I nearly lost a project when my HD crashed. I had my repo checked in AND go deps set up and it still took me a solid day of wrangling to recover a project. For all my kvetching about bower and maven, when I set them up they tend to stay set up and so the right thing. Go projects decay. Add that to the language's total punt on error handling and sync semantics so crazy that the ecosystem got a basic race detector before a basic interactive execution tool... I just don't get why this ecosystem has adherents.
- jzelinskie 11y ago
  >The cross compilation is also a thing I guess? I just use docker anyways. Docker does not make anything crossplatform; it just enables you to package your dependencies such that you can easily run on any other linux-amd64 machine. Go applications usually don't have many dependencies so Docker usually doesn't buy you much if anything at all. >But no... I mean... I can get a lot of editors to do a better job of formatting. I've never used a language with an ecosystem that so adamantly abided by one standard format. PEP8 comes somewhat close, but there are still fights over different linters etc... >Go get provides no realistic versioning other than "this is what I grabbed RIGHT NOW The vendor directory introduced in Go 1.6 (and usable in Go 1.5) has addressed the versioning issue with `go get`. I agree creating/updating vendored dependencies can be tricky depending on the tool you use and having a Go workspace per project is slightly cumbersome (though no less cumbersome than say virtualenv), but even before Go "officially" supported vendoring, going from zero to development is literally just `git clone` and `godep restore`. Go projects do not decay if you've vendored your dependencies. >so crazy that the ecosystem got a basic race detector before a basic interactive execution tool... Am I crazy that I prefer having a race detector over a REPL? There were plenty of REPL projects that never gained traction because you can develop pretty easily without them. I usually jump into the playground[0] if I need to test something. This has the added advantage of being sharable after I write it, too. [0]: https://play.golang.org https://play.golang.org
  - KirinDave 11y ago
    > Docker does not make anything crossplatform; it just enables you to package your dependencies such that you can easily run on any other linux-amd64 machine. Which IS the primary use case for nearly all of Go's interesting use cases. The exceptions are CLIs for API access? But you're going to have some trickiness with testing in these cases that warrant a non-trivial build-test cycle anyways. If that works well for you that's wonderful. A good packaging of Go with some helper shell commands is also quite nice, for other reasons. > I've never used a language with an ecosystem that so adamantly abided by one standard format. PEP8 comes somewhat close, but there are still fights over different linters etc... You say this like it's a good thing. I see only the downsides. I'm not much of a fan of Python's contemptuous ecosystem either. > The vendor directory introduced in Go 1.6 (and usable in Go 1.5) has addressed the versioning issue with `go get`. It most assuredly has not addressed this issue. All it's done is decreased the confusing filesystem zigguraut so that a single repo checkin doesn't look patently ridiculous. Pretty important when GitHub is the primary code distribution mechanism. But so long as the maintainers of Go pretend that everyone will always keep master up to date and never make breaking changes, Go projects are still at a disadvantage compared to every other civilized combiled build+deps tool. I had high hopes for Go vendoring, but examinations in 1.5 really reinforced to me that the maintainers and designers of Go are interested in the (less compliant) real world issues everyone runs into, don't care about shipping reusable code to a wide audience over a long period of time. Languages with contempt for programmers as a central tenant often have problems like these. > Go projects do not decay if you've vendored your dependencies. Hope you don't have a library with bugs. I sure found many in the libraries I pulled and if I put down a server for a month to work on something else, then tried to grab a security update? It was never not a headache. > Am I crazy that I prefer having a race detector over a REPL? I only refer to situations and inanimate objects as crazy. Anything else is disrespectful. You awknolwedge interactive development is necessary but don't want first class support for it. I just don't understand why you wouldn't want to actually have something that could integrate into a real workflow. Sharability is something we already can get with trivial pastebin/gist integration.

You don't think go build, go fmt, etc. are great? I agree there are deficiencies, but a lot of my day to day (admittedly in emacs) is pretty great.

by boulos 11y ago

You don't think go build, go fmt, etc. are great? I agree there are deficiencies, but a lot of my day to day (admittedly in emacs) is pretty great.

JBReefer 11y ago

Those are nice, but "great tooling" is Visual Studio or better, at a minimum.

KirinDave 11y ago
Not all languages with VS support or even VSC support have "great tooling." It's a very complicated set of balances and acceptance criterion.
KirinDave 11y ago
Not all languages with VS support or even VSC support have "great tooling." It's a very complicated set of balances and acceptance criterion.
KirinDave 11y ago
Not all languages with VS support or even VSC support have "great tooling." It's a very complicated set of balances and acceptance criterion.

KirinDave 11y ago

The compiler is very fast, and in absence of interactive development that's good. The cross compilation is also a thing I guess? I just use docker anyways. But no... I mean... I can get a lot of editors to do a better job of formatting. Other languages I use offer true interactive development. And go build requires a Zigguraut Of Filesystem around it to function properly. Go get provides no realistic versioning other than "this is what I grabbed RIGHT NOW and I hope you don't need bugfixes because good luck with figuring out the hash I got." The lack of reproducible builds and better tooling for versioning is a pretty damning stroke against the ecosystem, because I nearly lost a project when my HD crashed. I had my repo checked in AND go deps set up and it still took me a solid day of wrangling to recover a project. For all my kvetching about bower and maven, when I set them up they tend to stay set up and so the right thing. Go projects decay. Add that to the language's total punt on error handling and sync semantics so crazy that the ecosystem got a basic race detector before a basic interactive execution tool... I just don't get why this ecosystem has adherents.

jzelinskie 11y ago
>The cross compilation is also a thing I guess? I just use docker anyways. Docker does not make anything crossplatform; it just enables you to package your dependencies such that you can easily run on any other linux-amd64 machine. Go applications usually don't have many dependencies so Docker usually doesn't buy you much if anything at all. >But no... I mean... I can get a lot of editors to do a better job of formatting. I've never used a language with an ecosystem that so adamantly abided by one standard format. PEP8 comes somewhat close, but there are still fights over different linters etc... >Go get provides no realistic versioning other than "this is what I grabbed RIGHT NOW The vendor directory introduced in Go 1.6 (and usable in Go 1.5) has addressed the versioning issue with `go get`. I agree creating/updating vendored dependencies can be tricky depending on the tool you use and having a Go workspace per project is slightly cumbersome (though no less cumbersome than say virtualenv), but even before Go "officially" supported vendoring, going from zero to development is literally just `git clone` and `godep restore`. Go projects do not decay if you've vendored your dependencies. >so crazy that the ecosystem got a basic race detector before a basic interactive execution tool... Am I crazy that I prefer having a race detector over a REPL? There were plenty of REPL projects that never gained traction because you can develop pretty easily without them. I usually jump into the playground[0] if I need to test something. This has the added advantage of being sharable after I write it, too. [0]: https://play.golang.org https://play.golang.org
- KirinDave 11y ago
  > Docker does not make anything crossplatform; it just enables you to package your dependencies such that you can easily run on any other linux-amd64 machine. Which IS the primary use case for nearly all of Go's interesting use cases. The exceptions are CLIs for API access? But you're going to have some trickiness with testing in these cases that warrant a non-trivial build-test cycle anyways. If that works well for you that's wonderful. A good packaging of Go with some helper shell commands is also quite nice, for other reasons. > I've never used a language with an ecosystem that so adamantly abided by one standard format. PEP8 comes somewhat close, but there are still fights over different linters etc... You say this like it's a good thing. I see only the downsides. I'm not much of a fan of Python's contemptuous ecosystem either. > The vendor directory introduced in Go 1.6 (and usable in Go 1.5) has addressed the versioning issue with `go get`. It most assuredly has not addressed this issue. All it's done is decreased the confusing filesystem zigguraut so that a single repo checkin doesn't look patently ridiculous. Pretty important when GitHub is the primary code distribution mechanism. But so long as the maintainers of Go pretend that everyone will always keep master up to date and never make breaking changes, Go projects are still at a disadvantage compared to every other civilized combiled build+deps tool. I had high hopes for Go vendoring, but examinations in 1.5 really reinforced to me that the maintainers and designers of Go are interested in the (less compliant) real world issues everyone runs into, don't care about shipping reusable code to a wide audience over a long period of time. Languages with contempt for programmers as a central tenant often have problems like these. > Go projects do not decay if you've vendored your dependencies. Hope you don't have a library with bugs. I sure found many in the libraries I pulled and if I put down a server for a month to work on something else, then tried to grab a security update? It was never not a headache. > Am I crazy that I prefer having a race detector over a REPL? I only refer to situations and inanimate objects as crazy. Anything else is disrespectful. You awknolwedge interactive development is necessary but don't want first class support for it. I just don't understand why you wouldn't want to actually have something that could integrate into a real workflow. Sharability is something we already can get with trivial pastebin/gist integration.