Going


TL;DR: Not yet.

I’ve been mulling for a while whether I should switch to Go for my hobby projects, and have been tinkering with it somewhat along with a few of my colleagues. There is quite a bit about it to like, actually – especially if, like me, you develop REST APIs or back-end services that require sane, scalable approaches to concurrency and event handling.

In particular, I like it because it has:

  1. Mostly clean, simple syntax (except for the horrid := short assignment operator, which reminds me of my Pascal and Modula 2 days)
  2. Clear coding guidelines and conventions (even though I dislike the capitalised exports)
  3. A decent networking library
  4. Channels and Goroutines

But despite having done a few toy programs and benchmarks, I keep going up against a number of trifling irritations that prevent me from diving in and using it for real projects:

  1. Inconsistent performance (I’ve come up against weird slowdowns using string templating and HTTP)
  2. Lack of a built-in REPL (I am constantly trying out stuff in Python and JavaScript consoles, and a compiled language can’t match that)
  3. Small standard library (Python has clearly spoiled me in that regard)
  4. Remote module imports without clear version pinning (i.e., too easy to introduce brittle dependencies by default)
  5. Lack of critical mass (by which I mean knowledgeable folk who’ve used it in real projects themselves, or whom you could hire later on to maintain your own stuff after you’ve moved on)

All of these have been debated to death pretty much everywhere Go is mentioned, so if you’re thinking about sending off a counter-point, please don’t. I’m positive most of these will fade with time, although it’s hard to say how long.

Time is the matter here in more ways than one – I both envy current Go evangelists the time they’ve had to invest in the language, and lack the amount required to dive further in – something that’s unlikely to change while I’m very productive using Python or JavaScript and am able tackle either performance or concurrency issues with the tools those languages already provide.

So I’m staying put, but keeping an eye out.


See Also: