Learning Go after years of dynamic languages
I started writing Go about six months ago. At work, the backend ad services are in Go, so I did not really have a choice, and I am glad about that now.
My background is dynamic languages. Years of PHP, and more recently Ruby. So Go was a different way of thinking. This is not a tutorial, just some notes on what clicked and what annoyed me after half a year of it.
What clicked
Explicit error handling. In PHP and Ruby I throw and rescue exceptions, and errors can come flying out of anywhere. In Go, a function returns an error as a value, and you handle it right there. At first this felt primitive. Now I find it easier to reason about, because I can see exactly where things can go wrong by reading top to bottom.
Zero values. Every type has a sensible default. A string is "", an int is 0, a bool is false, a map or slice starts empty. So you do not get the “undefined variable” surprises I was used to. Things are always something.
Goroutines. Starting a concurrent task is just go doSomething(). Compared to the contortions I remember from doing concurrency elsewhere, this felt almost too easy. Channels took me a bit longer to get comfortable with, but the basic model is nice.
Fast compiles. The compiler is quick, so the feedback loop is tight. And it catches a lot of my mistakes before the code ever runs, which I did not have with PHP.
Small language. There is not much syntax to learn. I read through most of the language in a weekend. After Ruby, where there are five ways to do everything, having one obvious way is restful.
What annoyed me
The if err != nil thing. Yes, I just praised explicit errors. I also got tired of typing this:
result, err := doSomething()
if err != nil {
return nil, err
}
over and over. The reasoning is good. The repetition still wears on you after the hundredth time.
Missing conveniences. Coming from Ruby I kept reaching for things that are not there. No map or select on a slice (you write the loop yourself). No nice one-liners for common collection operations. You write more code to do simple things. The code is clear, but it is more typing.
Where I landed
I do not love everything about Go, and I do not need to. What I have come to like is that the code is boring to read, in a good way. There are fewer clever tricks, so when I open a file I wrote three months ago I can actually follow it.
After years of languages that let me be clever, Go mostly stops me. I did not expect to appreciate that.