Original post

Yeah, so I started writing at work last year, and I actually haven’t written Go for that much time. When I worked at Pivotal, a bunch of teams had basically adapter code that was in Go… So I didn’t get super-deep into Go my first two years there. Mostly my Go code was about taking YAML that’s in this shape and then marshaling it into a data structure and changing it into a slightly different shape… Which is kind of like what app developers do; you get some input, change it around a little bit, and then output it to somewhere else.

Last year I rolled on to a team that was working on an open source product called Concourse CI. Concourse is written 100% in Go. I think that was a pretty deliberate decision early on, because Concourse, first of all, needs to be highly performant. It’s a CI/CD system. It’s run on containers. A lot of the container APIs are written in Go, which is fantastic. Runc for example has a Go client… So I started learning a little more about Go, and trying to get more into the weeds of the language. And I definitely am still very far from being able to call myself a Go expert, but some of the things that I really like about Go is – believe it or not, I was actually thinking about this the other day… Learning Go conventions and the Go style of coding actually made me a better developer in other languages… And I feel like I go through this every time I learn a new language. Learning JavaScript made me better at Ruby, and now I feel like learning Go made me better at both JavaScript and Ruby…

[00:08:11.05] And I’ll tell you why – the reason why is because I love that Go is so opinionated. If you wanna write a conditional, there’s only one way to do it. So if you read a conditional in someone else’s code, it looks the same everywhere… And it’s stuff like that, that low-level stuff. There’s no reason to want to be creative with that, unless you’re playing code golf, or something I guess… Which I guess you can write your own macros and things if you wanna do that. But I really like that when you’re reading Go code, all you have to learn is the domain. You don’t need to learn a whole different set of conventions. This is something that I’ve struggled with with reading Ruby and JavaScript code for many years… Because at pretty much every job I’ve had that’s been in Ruby or JavaScript, we’ve always had a debate about what styleguide we wanna use… And this is always just such a timesink, because it doesn’t matter. Ultimately, you should pick one and introduce some automation that enforces it. It’s not a good use of developer energy.

I have this idea, I think every team has a certain amount of – almost like a friction budget. There’s a healthy amount of disagreement that every team can go through, but you still feel good about what you’ve done at the end of the day. Some teams have a higher friction budget than other teams, depending on how gelled you are… But it’s not a good use of that friction budget to argue about things like syntax and styling. You should spend that energy arguing about bigger things, like “Are we actually serving our users? Are we actually architecting our systems in the right way, or are we thinking about scale?” You know, the more interesting, open-ended questions… Not like “Oh, how many lines do you want your conditional to have?” That’s not a good debate to have. So that’s the first reason.

The second reason I really like Go is because I actually think – I’ve spent a lot of time thinking about the structure of functions, and I really love that Go, by and large, if you want to know what the happy path, the intended return value of a function is, you look at the bottom; the last line is your happy path. And many Go testing libraries – or not the testing libraries themselves, but the way that people write tests kind of reinforce this standard.

I think about, when I make a method call, the execution kind of ping-pongs through kind of like a pinball machine… You know, when you play pinball, the ball goes through the top and it goes down to all the flippers, and I visualize myself like flippering away the edge cases… So at the bottom, all that’s left is the straight path. With that sort of mental image I started thinking more about how the Ruby code, and the JavaScript code, and the code in other languages that I’ve struggled to read the most has always been code that has a lot of cyclomatic complexity – a lot of conditionals, a lot of nested statements, a lot of visual misdirection. So sometimes the happy path will be nested inside three layers of ifs, and it’s like “Well, how was I supposed to know that?”