24 ms·

Go's Tooling Is an Undervalued Technology

459 points by dilap 7y ago

spectramax 7y ago
I played around with Go for the first time. The package manager and process of creating a new project was refreshing! It’s so tidy and neat. Those are the first words that I thought of - Go is a very tidy and neat language. From syntax to publishing packages, the language has extreme levels of cleanliness.
- wildchild 7y ago
  Like tons of shadowing, lack of normal error management? > project was refreshing LOL many people disagree with that GOPATH bullshit.
nerdbaggy 7y ago
I love all the other commands for Go. I love the pprof, it’s so powerful. https://golang.org/pkg/net/http/pprof/ https://golang.org/pkg/net/http/pprof/ and all their other commands are great https://golang.org/cmd/go/ https://golang.org/cmd/go/
ggregoire 7y ago
I expected a section about testing and benchmarking since it comes out of the box with Go. Are there other popular languages offering it?
- maccam94 7y ago
  Rust's cargo CLI includes subcommands for testing and benchmarking.
- steve_adams_86 7y ago
  Python has the unittest module which works well for basic unit testing, and it's inspired by others (JUnit and the smalltalk testing framework respectively as I recall). I'm not sure about benchmarks, though.
  - ggregoire 7y ago
    Well, TIL! I had no idea about the unittest module. I always see pytest used in Python projects.
    - sitkack 7y ago
      That is because unittest should be removed from the core libs. It is a bad copy of a Java library, pytest is far superior in every way. There is no reason to use unittest.
      - masklinn 7y ago
        Well there’s the reason that it avoids pulling in a dependency. Which arguably is not much considering all the benefits of pytest.
        sitkack 7y ago
        If you are airgapped, you have other problems. They weren't really my target market.
- apta 7y ago
  Both the JVM and .NET have benchmarking suites. Java's JMH is arguably much more advanced and holistic than what is included with golang.
- mhh__ 7y ago
  D has unittests and potentially benchmarking if I can be bothered to implement it and write the proposal (and it gets accepted etc.) I have written a library solution using ranges at compile time to measure asymptotic performance but I'm talking about a language feature.
- yxhuvud 7y ago
  Are there any languages except C and C++ that doesn't?
m463 7y ago
I enjoy this sort of craftsmanship in software. It's also a very practical way of assuring wide adoption. A weird side-effect is that it makes mediocre software just that much more annoying and easy to bail on.
tmountain 7y ago
As an additional plus, you can apple-click "builtin" functions from inside of VSCode and drill into core libs for debugging purposes (adding breakpoints, log statements, etc). I've done this on a number of occasions to quickly get the result from an external HTTP request, etc. Go truly feels like a hacker's language that lets you get under the hood really easily when necessary.
- mhh__ 7y ago
  Is that not normal? The only languages I don't do that in (if needed) are C++ (STL code makes my eyes bleed), and C (no need - too basic). That being said if you need to add a breakpoint into stdlib code then God help you? (never used go so can't comment)
  - ebeip90 7y ago
    Setting breakpoints on CPython native code is a PITA and can’t be done (afaik) from PDB.
    - deleted 7y ago
      [deleted]
    - 1337shadow 7y ago
      Doesn't b do the trick for you ? b(reak) [ ([filename:]lineno | function) [, condition] ] Without argument, list all breaks. With a line number argument, set a break at this line in the current file. With a function name, set a break at the first executable line of that function. If a second argument is present, it is a string specifying an expression which must evaluate to true before the breakpoint is honored. The line number may be prefixed with a filename and a colon, to specify a breakpoint in another file (probably one that hasn't been loaded yet). The file is searched for on sys.path; the .py suffix may be omitted.
      - ebeip90 7y ago
jcalabro 7y ago
I definitely appreciate many parts of go's tooling ecosystem: pprof, gofmt, go get (in GOPATH mode), and go bug are all pretty good ideas. pprof in particular and the various profiling tools build out around it are great. That being said, I haven't found all aspects to be as nice - most notably among these is the lack of a good debugging environment. There is no debugger in the go tool, and users rely on delve[0] for their debugging needs. The dlv command line tool has actually gotten a lot better over the last couple years (props to the maintainers!), but integration in to visual front-ends is still lacking. VS Code and GoLand integrations at least are lacking to the point of it being nearly unusable except in the simplest cases. For a few examples, stepping is painfully slow (there are several machines/OSes I use), conditional breakpoints don't seem to work, keeping the tools up to date doesn't work consistently which means updating the underlying go/delve tooling or the IDE will frequently break the experience, and defining your debugging processes (e.g. via VS Code's launch.json) is tedious. None of these are go's fault per se, but it diminishes the overall experience. In general, it would be nice to have a better debugging experience, esp. since I prefer a GUI tool to the command line for debugging. In the meantime, I might switch back to just using command line dlv. But regardless, definitely agreed that go's tooling on the whole is great. pprof has saved my skin on countless occassions! [0] https://github.com/go-delve/delve https://github.com/go-delve/delve
- kortex 7y ago
  I feel your pain with the debugging and I have a feeling this will be an aspect of go which matures greatly in time. Especially with respect to goroutines, it can be tough tracing the program flow, which makes good debuggers even more valuable. Also a very hard challenge. I'd love to be able to see a diagram of goroutines and channels, like a chemical plant. That's probably asking for too much :p
- odsb 7y ago
  Do people really use a debugger ? This is a serious question because in 5+ years of programming I have never used a debuggers. The only time I used a debugger was when I was learning to program and to trace out for loops. Now I just use print statements and read code to figure out what’s going on.
arcticbull 7y ago
Go's compiler toolchain is an overvalued monstrosity, a relic from the 70's only Rob Pike could get away with resurrecting. Imagine walking into your day job and saying to solve today's problem you're going to blow the dust off your old floppy disks and see what they've got in store. It's like Tesla deciding that before they built a car, they'd have to pave a new highway from SF to LA. Someone's already done the paving, focus on what you bring to the table. LLVM is clearly the future. Yes, it could be improved, but of course all the effort that went into resurrecting the geriatric Go compiler didn't go into improving LLVM. It went into re-implementing assemblers for various architectures as though that wasn't a solved problem 100 times over. As for package management and vendoring, both are great, and should be table stakes, so credit where due on that one.
- pm90 7y ago
  What specifically about LLVM do you think makes it better than golangs compiler toolchain?
  - millstone 7y ago
    Its optimizations.
  - arcticbull 7y ago
    Not rewriting all the assemblers, linkers and optimization passes of which decades worth of PhDs went into LLVM. It was a total and utter waste of time re-doing all that. Any work that went into buffing up 9c is never going to make it back to the community, whereas anything that goes into LLVM makes the whole world a little bit faster, immediately. And they could have started there.
    - blinkingled 7y ago
      Ditto for gccgo - it still is a thing but they had to have their own everything and make gccgo a secondary implementation that lags behind mainstream. NIH maybe.
- kortex 7y ago
kstenerud 7y ago
Go's tooling is very nice compared to most other dev technologies, and the source is quite hackable as well. I made a 1-commit modification to the compiler that adds a flag -warnunused to make it stop failing on unused imports or variables [1], and it was remarkably simple to do in the go src tree. Plus, it's super easy for other people to use. Just check out the modified source, make.bash, and you're done in less than a minute of compilation! I may not agree with some of their philosophies, but the tooling is nice! [1] https://github.com/kstenerud/go https://github.com/kstenerud/go
- candiddevmike 7y ago
  Can you expand on the use case for your change? Why would you want unused imports or variables?
  - ebeip90 7y ago
    When actively developing code, it can be useful for warnings to go away. Get things to work, then make it tidy.
  - kstenerud 7y ago
    When I'm debugging something, I don't want compiling to fail just because I've commented out the only line that uses the net/url package. If I temporarily modify a function call to use a literal instead of a variable so I can test an assumption, I don't want it to refuse to compile just because that variable is now "unused". The cascade effect of this can get quite extensive and annoying. Same goes for exploratory programming, where I'm testing out ideas rather than writing production code. I expect my tools to get out of my way rather than play nanny.
    - loopz 7y ago
      Alternatively just add usages at top of package that have no real effects. This is experimental code after all! Never had problems with this, but yes, it's a bit different.
kortex 7y ago
When I first got into go, a few of the Go Opinions kinda rubbed me the wrong way. - I have to source GOPATH in my rc files? Annoying. - File paths are network URI's? Ugly. - I have to deal with every err != nil? Verbose. But over time I've grown to love go more than almost any language (python is still bae, especially with type hints, and even then, it's close). - dependency pathing is a pain in most other languages. Singular source of truth is great (I've had virtualenvs leak and cmake do bizarre things when multiple libs are on the file tree) - host/paths are file/paths. I love this pattern now. It's just so obvious and natural. - ok the err != nil still drives me nuts. But it drives me to write things in a way where I don't need to deal with errors as much. Reduces fractal complexity and paths through the code. It also forces "the buck stops here" sort of pattern where you have some atrium which is resiliant and is where most errors bubble up to
- ShorsHammer 7y ago
  installing or updating go is still a massive pain, it's mind-boggling why you'd have a modern language that behaves this way
  - sagichmal 7y ago
    brew install go?
  - ruffrey 7y ago
    I have not experienced problems installing or updating go in 5 years of use. What problems have you experienced?
    - ShorsHammer 7y ago
      Nor have I had problems, simply saying it is too much hassle for little gain so I rarely bother, whereas with other languages it is a breeze so I update all the time. Please document your workflow to update and compare it to other modern langs, it's all relative.
      - 7y ago
thrwaway69 7y ago
The part about building go is neat in comparison to other languages. I don't see the fresh breathe of ideas in package management. People used to host code and directly import it before go even released publicly. Go get was a thin wrapper over traditional way of downloading code and putting it in your folders if anything (wget). Ignoring the other advancement that took too long for go package management situation to resolve, currently I don't see any advantage go has over other languages in that area. Node package managers have allowed you to install packages from "decentralised" sources such as github or gitlab for a long time. node_modules is similar to vendor and with nexe, you can package them all into a single executable. Cargo provides all of that with additional features that neither of them do. Go developers butchered community experiment in the form of dep. While it had many problems but those didn't require abandoning it out of nowhere, this isn't the first time that has happened. The community has a knee jerk reaction to anyone providing suggestions to change something or better it. Failure of go type system (other than generics) is often met with suggestions of code generation and doing some wackamole interface magic. To any problems in the standard tooling, the answer is to fork it and go away. I agree but other communities don't behave that way. People are separated into distinct camp when it comes to promises or expectations. One noticeable idea is simplicity, half the crowd believes in the notion of verbal/syntactical, keywords and typesystem having less "features" simultaneously fighting for less ambiguity. The second half base simplicity on putting graduates to get up and working quickly in a code base at the cost of long term complexity in abstractions. All ideas of go make sense if you think from large company's perspective. You can notice how go would work well in a company with monorepos. That said. I hate go but that's why I like it too. If I want to get something done, I choose go. If i want to hack something and appreciate beauty of developing rather than efficiency or reaching end product, I avoid go like plaque.
pjmlp 7y ago
Go would be about right, had it been released around 1992, when we had Oberon, Oberon-2, Component Pascal, Modula-2+, Limbo making the university rounds. As it is, I see it mostly as C replacement. Yes, as C replacement, as projects like TamaGo, Android's GPU debugger, gVisor hypervisor, Go's bootstraped compiler, Fuchsia's TCP/IP stack, TinyGo for microcontrollers, show. However for anyone that enjoys being able to take advantage of what happened since 1992 in mainstream computing, Go isn't it.
- anderspitman 7y ago
  IDK. On paper I agree with you, but I'm just so darn productive with Go. C is great until I need to open a socket. Rust is awesome but slows me down. Dynamic languages need types for serious projects, and I can't be bothered to add a build step just for that. I use them all, but I only picked up Go relatively recently, and I've been very impressed.
  - pjmlp 7y ago
    I was also very productive with plenty of 80's and 90's languages, most of them more expressive than Go currently is, e.g. Turbo Pascal. From the research papers I usually read, plenty of others were quite productive with 60's and 70's languages, many of them more expressive than C. So while Go is a good contribution to reduce the amount of written C per year, it is hardly a novelty, including its compile speed.
    - pushpop 7y ago
      Your opinions of Go are quite clear, given every time there is a thread on HN about Go your relish telling everyone how backwards a language it is. Yet weirdly you’re not the only competent engineer out there. I’ve been programming for 30+ years and used many of the languages you’ve described. In fact I’ve written code professionally in well over a dozen different languages (I stopped counting somewhere in the last decade). Yet I still find myself productive in Go. It’s not just the compiler speed either. You talk as if people are idiots or are delusional when actually Go is quite a nice language for a great many people with real world problems to solve. I’m sure I’ll get downvoted for saying this but there is so much snobbery and elitism in these kinds of threads and it’s absurd. Live and let live guys.
thayne 7y ago
There are definitely good things about googles "decentralized package management". But using a url for the import also causes problems. What if the url the code is hosted on needs to change? And then I also ran into a case where I wanted to fork a dependency of a project, so I could get a bug-fix that hadn't been merged into upstream yet. But the only way I could figure out how to get it working was not only to have to change all of the imports in the main project, but a bunch of imports in the dependency as well to point to the fork. This seems needlessly painful.
- PhilippGille 7y ago
  > I wanted to fork a dependency of a project, so I could get a bug-fix that hadn't been merged into upstream yet. [...] change all of the imports in the main project, but a bunch of imports in the dependency as well to point to the fork. Isn't this solved with Go modules and the `replace` keyword in the go.mod file? It's meant to be used for exactly this purpose and the wiki uses the fork example as well: https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive https://github.com/golang/go/wiki/Modules#when-should-i-use-...
- didibus 7y ago
  Are we all going to pretend like we forgot Java has been using URIs for imports for 20+ years?
  - masklinn 7y ago
    The difference is that java’s “uris for import” is nothing more than a namespacing convention to avoid conflicts. A url in go is the actual place where `go get` will go retrieve the dependency, and the directory it’ll live at.
    - didibus 7y ago
      That's true, thinking from that angle it does seem more troublesome then, in cases where the URI goes down, or changes, or you need a personal fork.
- 7y ago
jayd16 7y ago
Eh, Java and C# and I'm sure plenty of others make this pretty simple as well. Go does seem to currently benefit from simplicity through lack of choice as it seems like there's only one way to do things, which is nice. I assume that'll eventually change as its not something you can really protect against and more the burden of success.
tsimionescu 7y ago
Coming from the C# and JVM world to go, tooling looked like one of the worst parts of Go. The debugging story is very limited: - No function execution - No edit-and-continue - No conditional breakpoints - No watchpoints Package management works OK on the consumption side, though it is much more clunky than with classic package managers (e.g. set an ENV variable to get a custom proxy, but write something in go.mod file to get a per-package proxy). However, the publishing side is all over the place: - Relies on source-control integration - Horrible import paths for packages published from large repos - Versioning based on source-control tagging, exact format undocumented - Major version changes require source-code level changes in all files touching the package - Multiple Go modules in same repo use-case is not documented (can you have separate versions from same commit? how do they reference each other?) The source-code level tools/plugins available are extremely basic (except for GoLand): - No refactoring support other than "rename variable" - Reference-finding across modules rarely seems to work - No way to automatically find all implementations of an interface - especially problematic in a language with implicit interface implementation - The tools are pretty slow, constantly re-parsing large chunks of code; go pls has fixed some of that
- morrbo 7y ago
  This nailed it for me. I came back to write some go last night after not writing it for a long time. The modules, go dep, etc stuff really put me off. Whereas beforehand (been writing stuff for a few years, not hobbyist, just not super complex) it was intriguing..now it seems like they've just moved on in one direction for packages. However, that direction is not really super well documented, intimidsting, and sure as hell doesn't work as well as nuget or npm.
- Meai 7y ago
  Go also doesn't compile as quickly as people make you think. A regular sized project will compile more slowly than a similar sized c# project.
  - vbezhenar 7y ago
    Do you compare it with C# AOT compilation?
didibus 7y ago
I don't really see how the package management in Go is better than in Java? In fact, it seems a bit inferior on some aspects, though mostly similar sounding overall. Can someone more familiar with both explain? I have to admit, the Go compiler is what I'm jealous of. No dependencies, not even GLIBC and cross compilation seems a breeze. SubstrateVM has a lot to catch up too there.
wildchild 7y ago
Go is poor language with toxic team and toxic community.
chris_overseas 7y ago
> If you already have a Go compiler on your system, there’s no reason to bother with binary releases. Just grab the source and build it. All can manage their own toolchain with ease! No thanks, give me binaries any day. I want to spend time developing my own software, not fiddling around bootstrapping a dev environment.
- philwelch 7y ago
  I agree with you and I found this part of the article strange as well, since one of Go's strengths is that it routinely spits out self-contained binaries thanks to doing exclusively static linking.
atilaneves 7y ago
... compared to C and C++. The reason why header-only libraries exist is because C and C++ don't have an official package manager. That's it. Any other language that does can vendor just as easily. Similarly, pretty much every other language has package management so that's not a point in Go's favour. From the article, we're left with compilation speed. That's actually important, but Go isn't the only language that has a reference compiler that runs fast!
- pornel 7y ago
  Also error messages from the tooling are still from a previous era. Nowadays tools say not just what's wrong, but go an extra mile to explain why and how to fix it. Go tools still print "go: your command was bad and you should feel bad. exit".
_pmf_ 7y ago
It's probably because Go programmers come from Java, where tooling is similarly great or better.
eeZah7Ux 7y ago
The level of hype around Go is absurd. The packaging and vendoring is a disaster. Not only the implementation, but the idea itself.
luord 7y ago
> [anything related to Go] is an undervalued technology What exactly has he been reading? I've been working in Go for a while now, after years of reading only praise for it. Except for the error handling, which is far from the only thing wrong with the language/ecosystem, and even comments on that never fail to gather dozens of apologists. There's nothing undervalued about it. This article itself is an example and it features little I haven't read dozens of times. > Decentralized modules are great idea and avoid most of the issues of a centralized package repositories. But centralized package repositories are essentially an attempt to solve the problems of the wild west approach from before (which Go's way is more or less a throwback to, that only works better now thanks to platforms like github). Maybe they're a good thing? Is everyone else wrong? Questions for later.
pbnjay 7y ago
I find go doc, go fmt, go vet, gopls, etc to be much more undervalued than the compiler itself. I use these supporting tools much more frequently than I invoke the compiler (yeah they're related...) but TBH the huge selling point when I point people to Go is the developer support and ecosystem.
rezeroed 7y ago
The article has three sections: building Go, package management, and vendoring. The first is irrelevant to almost everyone. The other two are terrible. If that's supposed to be singing Go's praises then I think it says a lot that wasn't intended.

459 points by dilap 7y ago

I played around with Go for the first time. The package manager and process of creating a new project was refreshing! It’s so tidy and neat. Those are the first words that I thought of - Go is a very tidy and neat language. From syntax to publishing packages, the language has extreme levels of cleanliness.

wildchild 7y ago
Like tons of shadowing, lack of normal error management? > project was refreshing LOL many people disagree with that GOPATH bullshit.

nerdbaggy 7y ago

I love all the other commands for Go. I love the pprof, it’s so powerful. https://golang.org/pkg/net/http/pprof/ https://golang.org/pkg/net/http/pprof/ and all their other commands are great https://golang.org/cmd/go/ https://golang.org/cmd/go/

ggregoire 7y ago

I expected a section about testing and benchmarking since it comes out of the box with Go. Are there other popular languages offering it?

maccam94 7y ago
Rust's cargo CLI includes subcommands for testing and benchmarking.
steve_adams_86 7y ago
Python has the unittest module which works well for basic unit testing, and it's inspired by others (JUnit and the smalltalk testing framework respectively as I recall). I'm not sure about benchmarks, though.
- ggregoire 7y ago
  Well, TIL! I had no idea about the unittest module. I always see pytest used in Python projects.
  - sitkack 7y ago
    That is because unittest should be removed from the core libs. It is a bad copy of a Java library, pytest is far superior in every way. There is no reason to use unittest.
    - masklinn 7y ago
      Well there’s the reason that it avoids pulling in a dependency. Which arguably is not much considering all the benefits of pytest.
      - sitkack 7y ago
        If you are airgapped, you have other problems. They weren't really my target market.
apta 7y ago
Both the JVM and .NET have benchmarking suites. Java's JMH is arguably much more advanced and holistic than what is included with golang.
mhh__ 7y ago
D has unittests and potentially benchmarking if I can be bothered to implement it and write the proposal (and it gets accepted etc.) I have written a library solution using ranges at compile time to measure asymptotic performance but I'm talking about a language feature.
yxhuvud 7y ago
Are there any languages except C and C++ that doesn't?

m463 7y ago

I enjoy this sort of craftsmanship in software. It's also a very practical way of assuring wide adoption. A weird side-effect is that it makes mediocre software just that much more annoying and easy to bail on.

tmountain 7y ago

As an additional plus, you can apple-click "builtin" functions from inside of VSCode and drill into core libs for debugging purposes (adding breakpoints, log statements, etc). I've done this on a number of occasions to quickly get the result from an external HTTP request, etc. Go truly feels like a hacker's language that lets you get under the hood really easily when necessary.

mhh__ 7y ago
Is that not normal? The only languages I don't do that in (if needed) are C++ (STL code makes my eyes bleed), and C (no need - too basic). That being said if you need to add a breakpoint into stdlib code then God help you? (never used go so can't comment)
- ebeip90 7y ago
  Setting breakpoints on CPython native code is a PITA and can’t be done (afaik) from PDB.
  - deleted 7y ago
    [deleted]
  - 1337shadow 7y ago
    Doesn't b do the trick for you ? b(reak) [ ([filename:]lineno | function) [, condition] ] Without argument, list all breaks. With a line number argument, set a break at this line in the current file. With a function name, set a break at the first executable line of that function. If a second argument is present, it is a string specifying an expression which must evaluate to true before the breakpoint is honored. The line number may be prefixed with a filename and a colon, to specify a breakpoint in another file (probably one that hasn't been loaded yet). The file is searched for on sys.path; the .py suffix may be omitted.
    - ebeip90 7y ago

jcalabro 7y ago

I definitely appreciate many parts of go's tooling ecosystem: pprof, gofmt, go get (in GOPATH mode), and go bug are all pretty good ideas. pprof in particular and the various profiling tools build out around it are great. That being said, I haven't found all aspects to be as nice - most notably among these is the lack of a good debugging environment. There is no debugger in the go tool, and users rely on delve[0] for their debugging needs. The dlv command line tool has actually gotten a lot better over the last couple years (props to the maintainers!), but integration in to visual front-ends is still lacking. VS Code and GoLand integrations at least are lacking to the point of it being nearly unusable except in the simplest cases. For a few examples, stepping is painfully slow (there are several machines/OSes I use), conditional breakpoints don't seem to work, keeping the tools up to date doesn't work consistently which means updating the underlying go/delve tooling or the IDE will frequently break the experience, and defining your debugging processes (e.g. via VS Code's launch.json) is tedious. None of these are go's fault per se, but it diminishes the overall experience. In general, it would be nice to have a better debugging experience, esp. since I prefer a GUI tool to the command line for debugging. In the meantime, I might switch back to just using command line dlv. But regardless, definitely agreed that go's tooling on the whole is great. pprof has saved my skin on countless occassions! [0] https://github.com/go-delve/delve https://github.com/go-delve/delve

kortex 7y ago
I feel your pain with the debugging and I have a feeling this will be an aspect of go which matures greatly in time. Especially with respect to goroutines, it can be tough tracing the program flow, which makes good debuggers even more valuable. Also a very hard challenge. I'd love to be able to see a diagram of goroutines and channels, like a chemical plant. That's probably asking for too much :p
odsb 7y ago
Do people really use a debugger ? This is a serious question because in 5+ years of programming I have never used a debuggers. The only time I used a debugger was when I was learning to program and to trace out for loops. Now I just use print statements and read code to figure out what’s going on.

arcticbull 7y ago

Go's compiler toolchain is an overvalued monstrosity, a relic from the 70's only Rob Pike could get away with resurrecting. Imagine walking into your day job and saying to solve today's problem you're going to blow the dust off your old floppy disks and see what they've got in store. It's like Tesla deciding that before they built a car, they'd have to pave a new highway from SF to LA. Someone's already done the paving, focus on what you bring to the table. LLVM is clearly the future. Yes, it could be improved, but of course all the effort that went into resurrecting the geriatric Go compiler didn't go into improving LLVM. It went into re-implementing assemblers for various architectures as though that wasn't a solved problem 100 times over. As for package management and vendoring, both are great, and should be table stakes, so credit where due on that one.

pm90 7y ago
What specifically about LLVM do you think makes it better than golangs compiler toolchain?
- millstone 7y ago
  Its optimizations.
- arcticbull 7y ago
  Not rewriting all the assemblers, linkers and optimization passes of which decades worth of PhDs went into LLVM. It was a total and utter waste of time re-doing all that. Any work that went into buffing up 9c is never going to make it back to the community, whereas anything that goes into LLVM makes the whole world a little bit faster, immediately. And they could have started there.
  - blinkingled 7y ago
    Ditto for gccgo - it still is a thing but they had to have their own everything and make gccgo a secondary implementation that lags behind mainstream. NIH maybe.
kortex 7y ago

kstenerud 7y ago

Go's tooling is very nice compared to most other dev technologies, and the source is quite hackable as well. I made a 1-commit modification to the compiler that adds a flag -warnunused to make it stop failing on unused imports or variables [1], and it was remarkably simple to do in the go src tree. Plus, it's super easy for other people to use. Just check out the modified source, make.bash, and you're done in less than a minute of compilation! I may not agree with some of their philosophies, but the tooling is nice! [1] https://github.com/kstenerud/go https://github.com/kstenerud/go

candiddevmike 7y ago
Can you expand on the use case for your change? Why would you want unused imports or variables?
- ebeip90 7y ago
  When actively developing code, it can be useful for warnings to go away. Get things to work, then make it tidy.
- kstenerud 7y ago
  When I'm debugging something, I don't want compiling to fail just because I've commented out the only line that uses the net/url package. If I temporarily modify a function call to use a literal instead of a variable so I can test an assumption, I don't want it to refuse to compile just because that variable is now "unused". The cascade effect of this can get quite extensive and annoying. Same goes for exploratory programming, where I'm testing out ideas rather than writing production code. I expect my tools to get out of my way rather than play nanny.
  - loopz 7y ago
    Alternatively just add usages at top of package that have no real effects. This is experimental code after all! Never had problems with this, but yes, it's a bit different.

kortex 7y ago

When I first got into go, a few of the Go Opinions kinda rubbed me the wrong way. - I have to source GOPATH in my rc files? Annoying. - File paths are network URI's? Ugly. - I have to deal with every err != nil? Verbose. But over time I've grown to love go more than almost any language (python is still bae, especially with type hints, and even then, it's close). - dependency pathing is a pain in most other languages. Singular source of truth is great (I've had virtualenvs leak and cmake do bizarre things when multiple libs are on the file tree) - host/paths are file/paths. I love this pattern now. It's just so obvious and natural. - ok the err != nil still drives me nuts. But it drives me to write things in a way where I don't need to deal with errors as much. Reduces fractal complexity and paths through the code. It also forces "the buck stops here" sort of pattern where you have some atrium which is resiliant and is where most errors bubble up to

ShorsHammer 7y ago
installing or updating go is still a massive pain, it's mind-boggling why you'd have a modern language that behaves this way
- sagichmal 7y ago
  brew install go?
- ruffrey 7y ago
  I have not experienced problems installing or updating go in 5 years of use. What problems have you experienced?
  - ShorsHammer 7y ago
    Nor have I had problems, simply saying it is too much hassle for little gain so I rarely bother, whereas with other languages it is a breeze so I update all the time. Please document your workflow to update and compare it to other modern langs, it's all relative.
    - 7y ago

thrwaway69 7y ago

The part about building go is neat in comparison to other languages. I don't see the fresh breathe of ideas in package management. People used to host code and directly import it before go even released publicly. Go get was a thin wrapper over traditional way of downloading code and putting it in your folders if anything (wget). Ignoring the other advancement that took too long for go package management situation to resolve, currently I don't see any advantage go has over other languages in that area. Node package managers have allowed you to install packages from "decentralised" sources such as github or gitlab for a long time. node_modules is similar to vendor and with nexe, you can package them all into a single executable. Cargo provides all of that with additional features that neither of them do. Go developers butchered community experiment in the form of dep. While it had many problems but those didn't require abandoning it out of nowhere, this isn't the first time that has happened. The community has a knee jerk reaction to anyone providing suggestions to change something or better it. Failure of go type system (other than generics) is often met with suggestions of code generation and doing some wackamole interface magic. To any problems in the standard tooling, the answer is to fork it and go away. I agree but other communities don't behave that way. People are separated into distinct camp when it comes to promises or expectations. One noticeable idea is simplicity, half the crowd believes in the notion of verbal/syntactical, keywords and typesystem having less "features" simultaneously fighting for less ambiguity. The second half base simplicity on putting graduates to get up and working quickly in a code base at the cost of long term complexity in abstractions. All ideas of go make sense if you think from large company's perspective. You can notice how go would work well in a company with monorepos. That said. I hate go but that's why I like it too. If I want to get something done, I choose go. If i want to hack something and appreciate beauty of developing rather than efficiency or reaching end product, I avoid go like plaque.

pjmlp 7y ago

Go would be about right, had it been released around 1992, when we had Oberon, Oberon-2, Component Pascal, Modula-2+, Limbo making the university rounds. As it is, I see it mostly as C replacement. Yes, as C replacement, as projects like TamaGo, Android's GPU debugger, gVisor hypervisor, Go's bootstraped compiler, Fuchsia's TCP/IP stack, TinyGo for microcontrollers, show. However for anyone that enjoys being able to take advantage of what happened since 1992 in mainstream computing, Go isn't it.

anderspitman 7y ago
IDK. On paper I agree with you, but I'm just so darn productive with Go. C is great until I need to open a socket. Rust is awesome but slows me down. Dynamic languages need types for serious projects, and I can't be bothered to add a build step just for that. I use them all, but I only picked up Go relatively recently, and I've been very impressed.
- pjmlp 7y ago
  I was also very productive with plenty of 80's and 90's languages, most of them more expressive than Go currently is, e.g. Turbo Pascal. From the research papers I usually read, plenty of others were quite productive with 60's and 70's languages, many of them more expressive than C. So while Go is a good contribution to reduce the amount of written C per year, it is hardly a novelty, including its compile speed.
  - pushpop 7y ago
    Your opinions of Go are quite clear, given every time there is a thread on HN about Go your relish telling everyone how backwards a language it is. Yet weirdly you’re not the only competent engineer out there. I’ve been programming for 30+ years and used many of the languages you’ve described. In fact I’ve written code professionally in well over a dozen different languages (I stopped counting somewhere in the last decade). Yet I still find myself productive in Go. It’s not just the compiler speed either. You talk as if people are idiots or are delusional when actually Go is quite a nice language for a great many people with real world problems to solve. I’m sure I’ll get downvoted for saying this but there is so much snobbery and elitism in these kinds of threads and it’s absurd. Live and let live guys.

thayne 7y ago

There are definitely good things about googles "decentralized package management". But using a url for the import also causes problems. What if the url the code is hosted on needs to change? And then I also ran into a case where I wanted to fork a dependency of a project, so I could get a bug-fix that hadn't been merged into upstream yet. But the only way I could figure out how to get it working was not only to have to change all of the imports in the main project, but a bunch of imports in the dependency as well to point to the fork. This seems needlessly painful.

PhilippGille 7y ago
> I wanted to fork a dependency of a project, so I could get a bug-fix that hadn't been merged into upstream yet. [...] change all of the imports in the main project, but a bunch of imports in the dependency as well to point to the fork. Isn't this solved with Go modules and the `replace` keyword in the go.mod file? It's meant to be used for exactly this purpose and the wiki uses the fork example as well: https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive https://github.com/golang/go/wiki/Modules#when-should-i-use-...
didibus 7y ago
Are we all going to pretend like we forgot Java has been using URIs for imports for 20+ years?
- masklinn 7y ago
  The difference is that java’s “uris for import” is nothing more than a namespacing convention to avoid conflicts. A url in go is the actual place where `go get` will go retrieve the dependency, and the directory it’ll live at.
  - didibus 7y ago
    That's true, thinking from that angle it does seem more troublesome then, in cases where the URI goes down, or changes, or you need a personal fork.
7y ago

jayd16 7y ago

Eh, Java and C# and I'm sure plenty of others make this pretty simple as well. Go does seem to currently benefit from simplicity through lack of choice as it seems like there's only one way to do things, which is nice. I assume that'll eventually change as its not something you can really protect against and more the burden of success.

tsimionescu 7y ago

Coming from the C# and JVM world to go, tooling looked like one of the worst parts of Go. The debugging story is very limited: - No function execution - No edit-and-continue - No conditional breakpoints - No watchpoints Package management works OK on the consumption side, though it is much more clunky than with classic package managers (e.g. set an ENV variable to get a custom proxy, but write something in go.mod file to get a per-package proxy). However, the publishing side is all over the place: - Relies on source-control integration - Horrible import paths for packages published from large repos - Versioning based on source-control tagging, exact format undocumented - Major version changes require source-code level changes in all files touching the package - Multiple Go modules in same repo use-case is not documented (can you have separate versions from same commit? how do they reference each other?) The source-code level tools/plugins available are extremely basic (except for GoLand): - No refactoring support other than "rename variable" - Reference-finding across modules rarely seems to work - No way to automatically find all implementations of an interface - especially problematic in a language with implicit interface implementation - The tools are pretty slow, constantly re-parsing large chunks of code; go pls has fixed some of that

morrbo 7y ago
This nailed it for me. I came back to write some go last night after not writing it for a long time. The modules, go dep, etc stuff really put me off. Whereas beforehand (been writing stuff for a few years, not hobbyist, just not super complex) it was intriguing..now it seems like they've just moved on in one direction for packages. However, that direction is not really super well documented, intimidsting, and sure as hell doesn't work as well as nuget or npm.
Meai 7y ago
Go also doesn't compile as quickly as people make you think. A regular sized project will compile more slowly than a similar sized c# project.
- vbezhenar 7y ago
  Do you compare it with C# AOT compilation?

didibus 7y ago

I don't really see how the package management in Go is better than in Java? In fact, it seems a bit inferior on some aspects, though mostly similar sounding overall. Can someone more familiar with both explain? I have to admit, the Go compiler is what I'm jealous of. No dependencies, not even GLIBC and cross compilation seems a breeze. SubstrateVM has a lot to catch up too there.

wildchild 7y ago

Go is poor language with toxic team and toxic community.

chris_overseas 7y ago

> If you already have a Go compiler on your system, there’s no reason to bother with binary releases. Just grab the source and build it. All can manage their own toolchain with ease! No thanks, give me binaries any day. I want to spend time developing my own software, not fiddling around bootstrapping a dev environment.

philwelch 7y ago
I agree with you and I found this part of the article strange as well, since one of Go's strengths is that it routinely spits out self-contained binaries thanks to doing exclusively static linking.

atilaneves 7y ago

... compared to C and C++. The reason why header-only libraries exist is because C and C++ don't have an official package manager. That's it. Any other language that does can vendor just as easily. Similarly, pretty much every other language has package management so that's not a point in Go's favour. From the article, we're left with compilation speed. That's actually important, but Go isn't the only language that has a reference compiler that runs fast!

pornel 7y ago
Also error messages from the tooling are still from a previous era. Nowadays tools say not just what's wrong, but go an extra mile to explain why and how to fix it. Go tools still print "go: your command was bad and you should feel bad. exit".

_pmf_ 7y ago

It's probably because Go programmers come from Java, where tooling is similarly great or better.

eeZah7Ux 7y ago

The level of hype around Go is absurd. The packaging and vendoring is a disaster. Not only the implementation, but the idea itself.

luord 7y ago

> [anything related to Go] is an undervalued technology What exactly has he been reading? I've been working in Go for a while now, after years of reading only praise for it. Except for the error handling, which is far from the only thing wrong with the language/ecosystem, and even comments on that never fail to gather dozens of apologists. There's nothing undervalued about it. This article itself is an example and it features little I haven't read dozens of times. > Decentralized modules are great idea and avoid most of the issues of a centralized package repositories. But centralized package repositories are essentially an attempt to solve the problems of the wild west approach from before (which Go's way is more or less a throwback to, that only works better now thanks to platforms like github). Maybe they're a good thing? Is everyone else wrong? Questions for later.

pbnjay 7y ago

I find go doc, go fmt, go vet, gopls, etc to be much more undervalued than the compiler itself. I use these supporting tools much more frequently than I invoke the compiler (yeah they're related...) but TBH the huge selling point when I point people to Go is the developer support and ecosystem.

rezeroed 7y ago

The article has three sections: building Go, package management, and vendoring. The first is irrelevant to almost everyone. The other two are terrible. If that's supposed to be singing Go's praises then I think it says a lot that wasn't intended.