I learned Go about 5 years ago when I was CTO at a startup/scaleup. At the time, we were looking to move to a microservice architecture, and that shift gave us the opportunity to consider moving away from the incumbent language (Scala). As I read through the Go tutorials, my compiler-writing background came back to me and I found myself repeatedly thinking “That’s cool – I know why the Go team did that!” So I got hooked on the language design.

Learning

I have worked with many different computer languages over the years, so I was not surprised I could quickly get started writing Go programs after reading through the online documents and tutorials. But then when I saw a new co-op student (a.k.a. intern) learn Go and write a substantial prototype in their first two weeks on the job, it became clear that Go was much easier to learn than many other languages.

Writing code

As I started writing my first Go programs, the first thing that struck me was the blazing compiler speed. It was as fast or faster starting my application than many interpreted languages, yet it was a compiled program with a strongly typed language. (I have an affinity for strongly typed languages – I have spent way too much time tracking down obscure issues in my own code in dynamic typed languages, where the same issue would have been a compile error in a strongly typed language.) Even better, in Go I often don’t need to declare the type – the compiler figures it out.

I was impressed with the standard Go library – it included many of the capabilities required by modern applications – things like HTTP support, JSON handling and encryption. Many other languages required you to use a third-party library for these features, and often there were multiple competing libraries to choose from, adding another decision point for the developer. With Go, I could go to the standard library GoDoc and get started right away.

There were a few other language decisions that I found helpful. One is that the compiler figures out if you are returning a pointer to a local, and behind the scenes allocates the memory rather than using the stack. This prevents bugs, and I find the code more readable.

I also like that you don’t declare that you support an interface. I wasn’t sure I would like this at first because it isn’t obvious if a type implements a particular interface, but I found greater value in the fact that I wasn’t dependent on the code author (even if it was me!) to declare that the interface is implemented. This first hit home when I used fmt.Println() and it automatically used the String() method I had implemented even though it hadn’t occurred to me that I was implementing the Stringer interface.

The last feature I’ll note is the ability to do concurrent programming through channels and goroutines. The model is simple to understand yet powerful.

Reading code

After writing more Go code and starting to incorporate third party libraries, I had a realization that had never occurred to me before – as a developer, I spend a lot of time reading code. In fact, I probably spend more time reading code than writing it, once you start counting code reviews, debugging, and evaluating third-party libraries.

What was different about reading Go code? I would summarize it by “it all looks the same.” What do I mean by that? Go format ensures all the braces are in the same spot; capitalized identifiers are exported; there are no implicit conversions, even of internal types; and there is no overloading of operators, functions or methods. That means that with Go code, “what you see is what you get” with no hidden meaning. Of course, it doesn’t help me to understand a complicated algorithm, but it does mean that I can concentrate more on that algorithm because I don’t have to understand whether ‘+’ is overloaded, for example.

I was also pleasantly surprised when I used GoDoc on one of my projects, and discovered that I had semi-reasonable documentation without doing anything while writing the code other than adding comments on my functions and methods based on nagging from the IDE I was using. I did spend some time cleaning up the comments after that, but I’m not sure I would have even started that work if Go hadn’t given me a great starting point.

Testing code

Go test is part of the standard Go tools and supported by IDEs, making it easy to get started creating unit tests for my code. And like the standard Go library, having a standard way to do tests means I don’t have to evaluate external testing frameworks and select one. I can also understand the tests when I’m evaluating a third party library.

Even better, the default behavior running package tests in VSCode is to enable Go’s built-in code coverage. I had never taken code coverage seriously working in other languages, partly because it was often difficult to set up. But the immediate feedback (helped by the blazing compile speed) gamified this for me, and I found myself adding tests to increase code coverage (and finding new bugs along the way).

Go doesn’t allow circular dependencies between packages. While this has caused me some rethinking while writing code, I find it makes my testing regimen easier to think about – if I depend on a package, I can rely on that package to have its own tests covering its capabilities.

Deploying code

I learned Go at the same time we were migrating towards container-based microservices. In that environment, the fact that Go produces a single, self-contained executable makes it much easier and more efficient to build and manage containers. I can build a container layer with one single file, which is often a single-digit number of MB in size, compared to our prior JVM-based containers which started with hundreds of MB for the Java runtime then another layer for our application. (It is easy to forget how much this overhead ends up costing in production, particularly if you have hundreds or thousands of containers running).

Second, Go has built-in cross compiling capabilities so our development machines, containers and cloud hardware don’t all have to all be on the same processor or operating system. For example, I can use a Linux build machine to produce client executables for Linux, Mac and Windows. Again, this takes away a complicated decision process due to artificial constraints.

Finally, Go has established a well defined set of principles for versioning and compatibility. While not all pieces of this are enforced, having the principles from an authoritative source helps manage the real life challenges of keeping your software supply chain up to date. For example, it is strongly recommended that breaking changes require a new major version number. While not enforced, it leads the community to call out any open source package that violates this principle.

What do I miss?

I did miss generics; thankfully Go 1.18 added support. And I do wish the standard library offered immutable collections (like Scala and other functional languages). Embedding instead of inheritance works pretty much the same in many cases, but requires some deep thinking sometimes.

My most frequent coding mistake is when I should have used a pointer receiver for a method and didn’t, then modify the receiver expecting the changes to be visible when the method returns. The code looks correct, the right values get assigned if I use a debugger to step through or issue prints, but the changes disappear after the method returns. I think I would have preferred if receivers were immutable, it would have caught these errors at compile time, and in the few remaining cases where I wanted to modify the receiver I would have copied it to a local variable.

In conclusion

As you can tell, I am a huge fan of Go, from even before I joined Google. I am impressed by the language and ecosystem design, and by the implementation. For me, Go makes me a more productive developer and I’m more confident in the quality of the code I produce.

Go, give it a try!