The Road to Go

Original post written by Ted Kornish on January 20, 2015.

Criteria

When choosing the programming language for Argo’s foundational services six months ago, we aimed to optimize for three factors:

• Ease of scalability for a team of developers. We planned on growing our team fast and knew that engineers would need all the help they could get to make sense of a rapidly evolving codebase. It was important that we pick something which was either previously known by team members or simple enough to learn in a matter of days. Additionally, we considered the ability to catch certain classes of errors before runtime — whether via a compiler or other static type-checking solutions — a huge plus because it provided more guarantees about how our code works.
• Easily utilizable multi-core concurrency. We knew we would need to fetch and process data in parallel. Therefore, our choice needed the ability to carry out long-running simultaneous actions in a straightforward way. Every modern and mature, production-ready language supports concurrency, but we were looking for one which made writing concurrent code a truly joyful experience.
• Reasonably performant. Programming languages vary in speed of execution, especially for numerically intensive operations. Given the mathematically involved nature of our platform, we were willing to care a bit more about the difference between a 32-bit float and a 64-bit float than we might be for just a simple CRUD app.

No.js

The first prototype was written in Node.js, a technology with which both Ryan and I had experience. We figured that having a full Javascript stack (we use Angular & d3 on the client-side) and Node’s much-touted non-blocking, event-driven I/O would make for a performant application which was easy to hack on. However, by the time Argo decided to pivot a few months later, the romance of a full Javascript stack had worn off and we were racking up technical debt fast. Wrangling Node to work with mature relational databases á la Postgres (our preferred primary data store) and dealing with one-too-many function calls on improperly typed data metamodels took us back to the drawing board. Node simply wasn’t the right tool for our job.

We liked what we saw: a lightweight, simple language with first-class concurrency support, a compiler, and excellent tooling.

TJ’s Departure & Rewriting the Prototype

Over the summer, we heard about Node legend TJ Holowaychuk leaving Node.js for the Go language (sometimes called “golang”) which originated at Google. After some peremptory investigation, we liked what we saw: a lightweight, simple language with first-class concurrency support, a compiler, and excellent tooling. When we translated a nontrivial portion of our prototype’s business logic into Go for testing purposes, we found the experience such a joy that found it a no-brainer to write the next version of the product in Go from the ground up.

Go-ing forward

Thus far, Go has delivered on its promised benefits: we’ve found it to be an easy-to-use, easy-to-deploy distributed systems language. What it lacks in theoretical purity it makes up for with ruthless practicality. The language certainly has caveats: generic-less programming sometimes causes repetition and the young ecosystem means that we occasionally have to write our own modules. However, we’ve found that between the robust tooling, concurrency-ready language semantics and lightweight, easy-to-read syntax that it’s a language remarkably suited to our problem space. We look forward to using Go to power our servers on the way to more connections and greater discoveries.

Originally published at argo.io on January 20, 2015.