My concerns about Go

I recently spent several weeks developing a piece of software to scratch an itch. I wrote it in Golang. I’m not so sure that was a good idea anymore.

Golang is great

Many people have heard me sing praises of Golang, so this post might come as a bit of a surprise. Let me reiterate what I like about Go:

It’s tiny

The language footprint is pretty small. It’s a tiny but complete set of primitives which fit together in mostly predictable ways. I normally take a course on Udemy or read a book to understand a new programming language. With Go, I didn’t - it just made sense.

The ecosystem is rich

There’s a Go library for almost everything (we’ll contend with “almost” in a bit). It’s pretty easy to find someone who had a given problem before and decided to make a library solving it. Native interop with C means that, if someone wrote the bindings, a lot of stuff that’s primarily developed for C is available with a native interface.

It compiles for a lot of platforms

Windows, Linux, macOS, WASM - everything’s included in the box. The amount of code that can stay common between the platforms is nothing to scoff at, either.

It comes batteries included

Testing, linting, vetting - all of those come with the standard binary. It’s very easy to set up a CI pipeline which behaves the same way between your machine and any hosted runners - just run the same Golang version.

Where Golang is not so great

From the above, a picture emerges of a jack-of-all-trades language. That usually comes with a tradeoff: master of none. I feel like that is very much true for Golang. You can use it for almost anything, sure, but getting there will be a workout.

The piece of software I was building recently is a web service with a bit of frontend. I wanted a modest set of features:

• a JSON-speaking API
• validation of objects pushed to the backend to the frontend
• an authenticated and a public side to the API
• CORS and ETag support
• a database layer

I don’t think that’s a lot to ask. There even exists a framework that supports most of that, Gorilla. Imagine my surprise when I started building with Gorilla, went to the repo for something, and found this notice:

The Gorilla Toolkit is now in archive-mode, and is no longer actively maintained. You can read more below.

We’ll be putting the Gorilla project’s repositories into “archive mode” by the end of 2022.

And I was already pretty deep into the project with Gorilla. Well shit, gotta migrate now. Is there a way for a Golang package to tell go get it’s deprecated? Not that I found.

So I switched to Gin. Gin comes decidedly batteries not included. In fact, it requires so much boilerplate, there are at least three repositories displaying how to put the boilerplate together correctly. I managed, sure, but I was not very happy about it.

So: the ecosystem is rich, but if you want to do web development with Go, like I did, I urge you to pre-clench. It’s gonna sting.

It’s not an “everything” language

While there’s support for web servers and services in the standard library - barebones though it may be - there’s one area which gets no love from the stdlib that stands out to me. That is desktop applications. No problem with TUIs, that’s a solved problem with many great libraries. But full fat, desktop apps?

You either get Electron-like contraptions which use HTML and JS, libraries which draw their own controls (think React Native), or bindings for something like Gtk. The last one is the closest to what I’d like to do, but - by virtue of being C - they take forever to compile, and their API is… very C-like, to put it mildly. In other words: if web development with Go takes clenching, you’ll probably want to bite down on something for desktop development.

It’s supported by Google

And why is that bad, I hear you ask? I’m still salty about Reader, that’s why.

On a more serious note: Google also gave us Dart and Flutter. When it comes to Dart, I have yet to meet a company that has adopted Dart seriously. Last I interacted with something that was provably Dart, it was the Google Ad Exchange (and that thing was atrocious). It’s still seeing development, so that’s great for it, I guess.

Flutter… I don’t know how to feel about Flutter. I toyed with it, but similar to React Native it felt super awkward. In fact, when talking to engineering teams across the world, I couldn’t find anyone who adopted Flutter seriously either; when it was mentioned, it was usually in the context of “we evaluated it, but {we kept our native devs|went with React Native}”. It’s also still seeing development. That’s great for it, I guess.

And Golang is still seeing development. Today.

Does Google like {Dart|Flutter|Golang}? Will it still like it in ten years from now? I’m not trying to build software for the next year, I’m building for the next decade. There’s always benefits and tradeoffs to a massive organization supporting something. On the one hand, they’re funding the development, which is great; on the other, you gotta think about what happens when the funding stops. Google’s backyard is full of projects it liked at some point.

I’m still looking

I know that Ruby is not my “next decade” language; a lot of the gripes I have with it match the ones I have with Golang. Having given it some more thought, I don’t think Golang is it, either.

Where do I go from here? I have no idea. I’ll let you know when I find it.