Go, month 1

27 Jun 2018

Around 3 weeks ago I switched job, and am now wading my way through learning a new codebase, zfs and other storage systems, data science and as this blog post’s title would suggest, Go.

Being as I’ve always said “the right tool for the job” over language superiority, I was glad of the challenge and looking forward to learning Go, so here is my personal, and very brief rundown of Go, having come from Python and other C based languages.

What’s in

things borrowed from other languages which you would recognise

• Static typing
• Pointers
• Slice indexing for strings/arrays
• Basically, C but with a few syntax changes and without header files.

What’s new

stuff I haven’t seen in other languages

• Shorthands for static typing. blah, err := mymethod() will force go to infer the type for blah and err from the return signature of mymethod. This gets a little messy if you have either of the variables already defined, though.
• Channels and “goroutines”, allowing multithreading and communication between threads to be a little less boiler plate.
• Public/private exports of methods based on the case of the first letter for a given method. (I think?) You do also have to specify package whatever at the beginning first.
• Compilation errors based on the creator’s preference over what line braces fall on. i.e JavaScript and Java style, not C# style.
• “Slices” being a type
• The compilation output is a single binary, and it’s easy to do.

What’s out

stuff you totally notice is missing, for good and bad reasons

• try/catch, and with it, exceptions of any kind. Anything which can have problems needs to explicitly state it returns an error somewhere. This doesn’t mean your program can’t crash catastrophically, it just means really bad stuff is classed as a “panic”.
• Semi-colons!
• tabs vs spaces, and any other stupid program formatting arguments. Gofmt on save is a feature of many plugins (and if it isn’t, you should enable it).
• Inheritance and objects. Structs, pointers and interfaces can just be all the things, right?
• Unused variables. If you need to return something and then ignore it when it’s outta there, you have to use _ which you then cannot use anywhere.
• Decent package management. Go having come from a monorepo company means it just wasn’t thought about.

Conclusion

The main takeaway I have from Go is that it’s creators were very opinionated, as are most software engineers. C seems to be largely untouched, but like Python, elements of what they believe make readable code are compilation requirements over style recommendations. I’m a fan of the idea of enforcing readable code, but the downside of their love of C is that we’ve moved on since then. We’ve solved some problems like error handling, and avoiding code duplication and package management (well, kind of). All of those solutions seem to be ignored or else deemed to be unnecessary complication in Go. Dependency management just seem like it was completely forgotten and the community is now scrambling to recover from that.

At the moment I just feel very “meh” about it as a language. The main reason I’m given for why Go is so popular is it’s ability to abstract/soften the difficulties of multithreaded programming, so potentially I’m not feeling the hype because I’ve not done a lot of multithreaded code.

I’ve been a Pythonista for probably 3-4 years, and I never felt like it solved all issues or touted that everyone should just write things in Python, but large swathes of it seemed like a jump forward from what we had before, whereas large swathes of Go feel like someone’s pressed the pause button on a period of time they particularly liked and then forked and added to that timeline.