Tech News
← Back to articles

A case for Go as the best language for AI agents

read original related products more articles

I have been working with Go for the past 8 years in a professional capacity. I’d like to make a case here about why Go is the best language to work with using AI agents.

I have worked with PHP, Go, JavaScript, and Python in a professional capacity for over 10 years now. Most of my career has been building web services, and I have been building Bruin over the past few years, which is primarily a CLI tool written in Go.

Bruin is an open-source ETL tool, and as some of you might know, the data ecosystem loves (or used to love?) building tools in Python. There are a ton of available libraries, data people are familiar with Python, so it is easier to get contributions, and it is easy to find Python developers compared to Go. When we started building Bruin, we had to make a decision: do we build the CLI in Go or do we build it in Python?

We had a few constraints that we needed to take into account before we made a decision:

Bruin is a data orchestration tool, which means there’ll be a lot of stuff that needs to run concurrently.

Bruin needs to interact with a lot of different systems, such as language runtimes or external APIs for data platforms; therefore, we need a decent ecosystem around the language.

Bruin needs to be fast. It is a CLI tool, and we wanted to use it with various systems, such as VS Code extensions or local UIs as a backend, and it needed to have sufficient performance.

Bruin needs to have predictable error handling paths for all the different systems it has to integrate with, and inform the user explicitly.

Bruin will run on users’ machines, which means it should be easy to support various operating systems and architectures.

On top of all these constraints, there was a more subjective constraint as well: I would be the primary contributor for quite some time, and it had to be a language I enjoyed working with. Joy and energy is one of the rarest resources a small team can have when building large projects, and I felt it was crucial that I did not dread the tech stack we used.

... continue reading