Ari's Repository

Some time ago I started really running into the limitations of Python as a primary language to work with. Between the complexities of packaging and shipping a Python project to the slow run time by comparison to compiled languages (inb4 python isn't slow it's your code). After nearly a decade using Python for nearly everything, I finally decided to make the switch to something else.

Enter Go, stage left.

I tend to prefer simple solutions that imply great complexity. When comparing the options between C-likes, Rust, and Go, I ended up really being drawn to the sheer simplicity of the Go language. With only 25 keywords and a growing number of services that I use and love being built on Go, I was sold. After a decade of working with dynamically typed languages that will do almost anything, I was looking for something more declarative that would force me to design my data and lifecycle before I wrote code.

Python is great for prototyping, but a headache to revise and refine. Go takes longer to prototype, but makes revising and refining feel like a breeze.

Yes, Python is a wonderful language for prototyping. Yes, Python has an amazing ecosystem with solutions for just about any problem. But Python also makes some choices that feel... antiquated at best. For example, want to write docs that comply with the languages standards? Better learn this massive library with a million options! Want to do some basic http networking/API building? You should probably download a framework for that. Want to write unit tests for your project? You probably want pytest. Want to compile and distribute an immutable executable? You can if you try hard enough...

Go makes sensible choices for all of these issues. Want to write docs? Just add comments with plain language. Want to include tests? The built in testing conventions are batteries included. Want to do some API building? The standard library has you covered. Want to compile to a binary? Just hit go build. Every time I try to do something, the tooling is just better. Even the third party tooling feels better.

Python feels like a fully stocked tool shed. Go feels like a select few versatile tools that are built to last.

Most importantly, Go was built for the age of concurrency. Utilizing asynchronous processing isn't just a feature added to the language, it was a core design principle from the ground up. This really started to appeal to me after trying to write a python script to manage metadata on tens of thousands of raw photographs. The script, while fairly simple when implemented synchronously, became exceedingly difficult to maintain when implementing it asynchronously. It was entirely possible, but what was a sub 100 line script quickly bloomed into a project with object inheritance and more complexity than I care admit.

Reimplementing an asyncio python script as a go program resulted than fewer lines and a more efficient runtime.

As I've continued to port various scripts from python to go, I've seen this pattern repeat time and time again. When doing something well and quickly is more important than fast prototyping, Go reins supreme.

If you'd like to see my first project beyond a simple script, see pingo – my simple latency charting tool for the command line.

---

Ariana Giroux is an award winning advocate, musician, photographer, and computer nerd who can almost always be found with a good coffee in hand.

Ariana can be found elsewhere via her linktree