Before I start rambling I should probably apologise. No doubt I’ve shown some misunderstandings or lack of knowledge about Go that are completely unforgivable to anyone with more knowledge about server-side languages. However, this post is solely intended to express my experiences as a front-end developer (who is very new to Go) and how it compares to frontend technologies.
Go’s core library is powerful
I’ve found it easy to build an application with just the core library; it has good enough templating, http server and test framework to serve even some quite complex needs (although I have to mention that I’m not a huge fan of the default logging and the fact that a “panic” can shut your application down during runtime). Compare this with a NodeJS application, which usually means initialising with NPM and installing dependencies such as Express, http, Jest, Handlebars templating and Webpack to create what could still be a simple server.
Go is a low-level language
What I mean by this is that typically Go doesn’t try to abstract complexity away from the developer – which can be both negative and positive. For someone from a front-end background, who hasn’t had to deal with bytes, memory allocation or concurrency in much detail this has been a bit daunting. For those more experienced, I imagine it means the language can be powerful when used properly (so probably by someone other than me!) by being able to optimise exactly how code works, with very little being forced upon you by the language.
I’m still struggling to get to grips with just how low-level it is and I sometimes feel it’s more complex than it needs to be. For example, here is how we can take a request’s response body and turn it into a usable format:
From what I’ve read this approach to error handling can be quite divisive among developers. Some people feel it is too verbose and causes lots of unnecessary duplication, whereas others think it helps make sure developers consider what errors could happen and deal with them appropriately.
Gophers are cool
People who write Go like to refer to themselves as “Gophers”. This may seem nerdy but … well it is … but it does develop a great sense of community between Go developers. You also have an excuse to plaster your laptop with stickers of cute cartoon gophers like this:
Strongly typed languages rock
Will I always use Go instead of NodeJS now?
Most of the time … yes I will use Go instead of NodeJS, but there might be the odd occasion where NodeJS is more suitable. For example, I can build a prototype in NodeJS much quicker than I can in Go at the moment. I haven’t written huge amounts of server-side code, but in the past I would always use NodeJS (for obvious reasons) but I can really see that changing now. It’s quick to compile, the syntax is fairly common sense, it can be really performant and it teaches me new ways of writing code.