Yeah, so I started writing Go 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.
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.