I’ve been using Go for a while now, and really rather like it. However, the web doesn’t need another article fawning over why Go is better than language X or why it’s inferior to Z - there are plenty of those. I’m not writing another one.
The thing is, I don’t think the Go language is its strongest selling point. Python, Rust, even JavaScript have a number of superior features, so why do I continue to write code in Go?
I think it’s the tooling.
go docs
I daren’t count the hours of my life I’ve spent searching for code libraries and documentation, but it’s probably a terrifying number (anyone else who has worked with Java will know what I mean). The experience was always the same: a Google searchathon leading to a ghastly freakshow of project pages, inevitably filled with dead or old links to outdated libraries and unfulfilled promises of comprehensive “documentation”. Python and Node upped the game, but as a developer I’d rather read the docs I’m after than trying to time the circus of different tools required to generate them.
Go came along and put docs generation one command away - godoc. Of course, this wasn’t novel - we’ve had javadoc for years, but what came next was a bit of a revelation.
GoDoc provides complete, consistent and clean documentation for every open source Go library one can find on the web. It also doubles as a search engine, saving Go developers from having to dive back in to SourceForge-infested waters. Sounds simple - but it’s turned out to be quite a game changer. Being able to find libraries and read their documentation with absolutely no pain? Sold. I’ve become a bit addicted, searching daily for new or interesting libraries to play with, simply because it’s so accessible to find what I want on there.
Unfortunately, there is also a negative impact - I can hardly bear to look at Java 8 or Python 3 documentation over Go any more.
The fact that GoDoc (and the equally terrific GoWalker) make access to docs so easy has had an overall positive effect on the Go ecosystem too - it seems the vast majority of libraries have some documentation, and a rising percentage have excellent documentation. Driven perhaps by the fact developers can’t hide embarrassing, incomplete and outdated API docs behind a tiny link hidden in a CSS dropdown in some far-flung corner of their project webpage any more - Go puts it front and centre whether you like it or not. Can’t see docs for your favourite package? Tap in the name anyway and it’s instantly fetched, generated, indexed and presented for your - and everyone else’s - perusal.
(Do other languages have equivalent services? Where are pythondocs.org, javadocs.org or nodedocs.org? If these exist, please tell me - I’d love to use them.)
Writing docs is even easier - no @param parameter or <param>parameter</param> nonsense - just a clean, simple, readable comment above the respective piece of code. I’m sure meta-cruft will start to appear down the road but, for the moment, I’m basking in the XML-free sun as much as I can.
Also, GoDoc -http serves up docs over HTTP so I can browse all my local packages even when I haven’t got an internet connection. How cool is that?!
go test
If there’s one thing software developers hate more than writing documentation, it’s probably writing tests. Go makes that easier too: want to write a test for MyFunc? Write a function called TestMyFunc and run go test. Want to benchmark MyFunc? Write BenchmarkMyFunc and run go test -bench - it’ll even automatically adjust the test load as appropriate to get a good measurement within a reasonable time frame. Frankly, as a developer who was brought up on Java, C++ and Python, I find it quite ridiculous how easy Go makes this.
This is no technological breakthrough by any means - testing and benchmarking tools like these have existed in various forms for other languages for years - but rarely have they been such no-brainer experiences. The testing suite that comes with Go is not even particularly comprehensive (traditional asserts require a third party library, for example), but it’s more than good enough for the majority of cases and is augmented with ease.
go fmt
If the time spent debating whether to use tabs or spaces, indent widths, brace positioning, under-sentence-camel-capital-title casing, and the plethora of other life-or-death issues that taunt software developers every day was counted, collectively we’d run out of fingers, toes, and any willingness to live.
Even when languages ship with style guides, who really has the time to read them? Python has a beautifully concise style guide in the shape of PEP8, but even with this well-considered and clear tome to writing Python code, an alarming variety of Python coding styles exist in the wild. (I dare say the vast majority of Python programmers don’t even know about PEP8, let alone those that have read it.)
The trouble is, we want to write code that works and solves problems. Committing style guides to memory is rarely at the top of our to-do list.
Go’s solution to this problem - gofmt - automatically and reliably formats (‘beautifies') source code so it matches the canonical style. You may not agree with the decisions it makes, but tough - given the difficult choice between “tabs”, “spaces” or “consistency”, the latter will almost always win.
Brilliantly, gofmt neatly sits in the open-edit-save-run cycle of code development. Extensions like vim-go will run automatically gofmt for you when you save, ensuring that all source code always adheres to the style. It works very well, saves time, and helps bring subtle errors to the fore. It’s terrific.
If only there had been cfmt or or javafmt when we needed it…
go ftw
Regrettably, go ftw isn’t a supported command. I made it up. It does nothing. Go is not perfect.
The language has a number of features that - to some - are flaws, be it the lack of generics, the presence of a garbage collector, or the fact that it’s the product of a big multinational corporation starting with the same two letters of the alphabet. But there’s a lot that developers of other languages can learn from Go: the fantastic aspect about the tools I’ve described is not that they exist, nor that they work so well or efficiently, but the fact they come with the language as standard.
If you can compile Go code, you can format, test, and document it without additional configuration. It’s a welcome improvement over those languages that have come before (standing on the shoulders of giants and all that.)
I still occasionally find myself cursing it wishing for Python’s flexibility or Java’s [insert something I actually like about Java here]. Indeed, not all of Go’s tools listed here are unique to Go, but to me, Go feels like the first time they’ve been done right, and cohesively. In my opinion its most valuable contribution to programming society is this simple, consistent, empowering tooling that I sincerely hope other languages copy mercilessly.