On the server I mostly work in node.js, but I’ve been increasingly interested in Go recently. There’s plenty to recommend both platforms, but the things attracting me to Go are it’s ease of deployment and simplicity of ecosystem, among others.
Recently, I needed a utility to interact with the Cloudflare API. A simple dynamic DNS client that would set a CNAME record and keep it update when my ISP changes the IP address assigned to my home connection. It was a simple enough utility that I decided to write a version of it in each language.
The result is on github.
https://github.com/davidbanham/cloudflare_dyndns/blob/master/app.go
https://github.com/davidbanham/cloudflare_dyndns/blob/master/app.coffee
Each of the treatments individually is bad code. Neither of them is idiomatic for their platform. I’ve intentionally tried to keep them both the simplest way possible so they could each be similar in execution.
In the writing of them, I found it a lot easier to do the exploratory, hacking around stage in node. This is obviously primarily due to the fact that I’m vastly more experienced in it than Go. I think, however, it’s also down to the fact that node’s standard library is so much smaller. Something I tend to do a lot of when interfacing with a new API is making calls to it, then logging the response out to the terminal just to see what I’ve got. In node, this is just console.log. Everything is just console.log. In Go, I spent ages lost in the arcane invocations to fmt.Print and it’s variants. It turns out the magic words are fmt.Printf("%s\n", body). I would have been equally happy with os.Stdout.Write(body) but I didn’t know it existed at the time.
A large standard library is handy to have. I love node’s vibrant ecosystem and npm is a great resource of other’s people’s code. After having been burned badly by memory leaks in other people’s code, though, I’m increasingly reluctant to provide my dependency tree with too much fertiliser. If something is in Go’s standard library, I’ve got a reasonable assurance it’s solid.
The wonderful thing about Go is the security you get from the type system. If the thing compiles, it probably works the way you expect. In Java I constantly felt like I was wrestling the type system, but in Go it feels like we’re a team. The fact that the compile time is so quick is really wonderful, too.
I’ll be writing node for a while yet. THe size of the community and the industry adoption is growing every day and it’s a great place to be. I’ll definitely be keeping Go as part of my toolbelt, though, and using the best tool for the job at hand.