Go 1.11 got me to stop ignoring Go

Published 2018-10-08 on Drew DeVault's blog

I took a few looks at Go over the years, starting who knows when. My first serious attempt to sit down and learn some damn Go was in 2014, when I set a new personal best at almost 200 lines of code before I got sick of it. I kept returning to Go because I could see how much potential it had, but every time I was turned off for the same reason: GOPATH.

You see, GOPATH crossed a line. Go is opinionated, which is fine, but with GOPATH its opinions extended beyond my Go work and into the rest of my system. As a naive new Go user, I was prepared to accept their opinions on faith - but only within their domain. I already have opinions about how to use my computer. I knew Go was cool, but it could be the second coming of Christ, and so long as it was annoying to use and didn’t integrate with my workflow, I (rightfully) wouldn’t care.

Thankfully Go 1.11 solves this problem, and solves it delightfully well. I can now keep Go’s influence contained to the Go projects I work with, and in that environment I’m much more forgiving of anything it wants to do. And when considered in the vacuum of Go, what it wants to do is really compelling. Go modules are great, and probably the single best module system I’ve used in any programming language. Go 1.11 took my biggest complaint and turned it into one of my biggest compliments. Now that the One Big Problem is gone, I’ve really started to appreciate Go. Let me tell you about it.

The most important feature of Go is its simplicity. The language is small and it grows a small number of features in each release, which rarely touch the language itself. Some people see this as stagnation, but I see it as stability and I know that very little Go code in the wild, no matter how old, is going to be unidiomatic or fail to compile. Even setting aside stability, the conservative design of the language makes Go code in the wild remarkably consistent. Almost all third-party Go libraries are high quality stuff. Gofmt helps with this as well1. The limitations of the language and the way the stdlib gently nudges you into good patterns make it easy to write good Go code. Most of the “bad” Go libraries I’ve found are trying to work around Go’s limitations instead of embracing them.

There’s more. The concurrency model is superb. It should come as no surprise that a language built by the alumni of Plan 9 would earn high marks in this regard, and consequently you can scale your Go program up to be as concurrent as you want without even thinking about it. The standard library is also excellent - designed consistently and designed well, and I can count on one hand (or even one finger) the number of stdlib modules I’ve encountered that feel crusty. The type system is great, too. It’s the perfect balance of complexity and simplicity that often effortlessly grants these traits to the abstractions you make with it.

I’m not even slightly bothered by the lack of generics - years as a C programmer taught me not to need them, and I think most of the cases where they’re useful are to serve designs which are too complicated to use anyway. I do have some complaints, though. The concurrency model is great, but a bit too magical and implicit. Error handling is annoying, especially because finding the origin of the error is unforgivably difficult, but I don’t know how to improve it. The log module leaves a lot to be desired and can’t be changed because of legacy support. interface{} is annoying when you have to deal with it, like when dealing with JSON you can’t unmarshall into a struct.

My hope for the future of Go is that it will continue to embrace simplicity in the face of cries for complexity. I consider Go modules a runaway success compared to dep, and I hope to see this story repeated2 before hastily adding generics, better error handling, etc. Go doesn’t need to compete with anyone like Rust, and trying to will probably ruin what makes Go great. My one request of the Go team: don’t make changes in Go 2.0 which make the APIs of existing libraries unidiomatic.

Though I am growing very fond of it, by no means am I turning into a Go zealot. I still use C, Python, and more all the time and have no intention of stopping. A programming language which tries to fill all niches is a failed programming language. But, to those who were once like me: Go is good now! In fact, it’s great! Try it!

  1. I have minor gripes with gofmt, but the benefits make up for it beautifully. On the other hand, I have major gripes with PEP-8, and if you ever see me using it I want you to shoot me in the face. 

  2. Though hopefully with less drama. 

Have a comment on one of my posts? Start a discussion in my public inbox by sending an email to ~sircmpwn/public-inbox@lists.sr.ht [mailing list etiquette]


Articles from blogs I follow around the net

Announcing The New Go Store

We are excited to launch the new Go official swag and merch store shipping worldwide. We are even more excited to announce that 100% of the proceeds from the Go store go directly to GoBridge. GoBridge is a non-profit organization focused on building bridges…

via The Go Programming Language Blog July 18, 2019

Deconstruct files

This is a psuedo-transcript for a talk given at Deconstruct 2019. To make this accessible for people on slow connections as well as people using screen readers, the slides have been replaced by in-line text (the talk has ~120 slides; at an average of 20 k…

via Dan Luu July 12, 2019

Updates in June 2019

This post gives an overview of the recent updates to the Writing an OS in Rust blog and the used libraries and tools. My focus this month was to finish the Heap Allocation post, on which I had been working since March. I originally wanted to include a sect…

via Writing an OS in Rust July 6, 2019

Generated by openring