Antonio Ribeiro

With Go We Go

August 24, 2026

Python used to be my language of choice for toy projects. The reason was obvious: simple language, accessible, batteries included, and, above all, fun to use. The reason we code for joy is to, well, have joy.

Modern Python doesn’t give me joy. Don’t get me wrong, it is still a great language, and with an ecosystem that is second to none (the day I plugged SymPy and Numpy together and could solve LU decomposition in a system of equations using symbolic programming, boy oh boy, my mind almost exploded!). But I think modern Python is suffering from feature creep. Day after day, the Python I see being written gets further and further from the Python 2.4 I started loving.

And it is not as simple as “ignore the extra features and code your code simple”. This approach doesn’t fix it because Python is not only the language, it is the ecosystem. And the libraries we use are all adopting, each on it’s own way, a fraction of the this immense jungle of available features. As a result we have to be comfortable navigating codes with typing, type hints, positional only arguments, match case, lazy imports¹. Even if I don’t want to use such features, I have at least to understand it, specially when they are used in the API of a library I need. The language is creating built-in complexity, and the users are adopting the features (why wouldn’t they?).

The joy is gone, Python is getting Java-ish bureaucratization embedded in the language. Today, when I want to code a quick project to solve a punctual problem or do a quick hobby project I’m seeing myself more often electing Go as my language to go (wink wink).

Go is fun, simple, direct, unambiguous. It has a completely different ethos than Python (static typed, compiled to machine code, designed to build systems closer to the hardware), but for many of my side-projects, I can navigate Go restrictions and generate result with a cleaner code than I’m able to do with Python. And, although it has an ecosystem much smaller and restricted than Python (if I need to run LU decomposition using a symbolic solver, I’m crawling back to Python), for many small things like crunching some data and generating a HTML report with plots and text, I’m already happy enough doing that in Go.

I love Python. When I first started writing code in Python I called it my calligraphy practice paper for coding, because it forced me to write cleaner code than I was used to in C (my language of choice at the time). Now I have the same feeling for Go. At lest until v1.26, before the generic explosion.