An Economics Major Learns Go

July 5th, 2019

Go Gopher

I was 20 and had a startup idea. Inspired by StackOverflow, it was to be a live Q&A for people in the same class. It was to be called classfaq. I even saw a similar startup in Techcrunch and reached out to the founder. Unable to convince an engineer of the idea’s merits and full of recommendations to build a “MVP”, I set out to build it myself.

I choose Python. It was accessible, had a great community and most importantly my roommate knew it, so I could pepper him with questions. As a non-CS major, I’ve always been plagued with imposter syndrome: that I wasn’t really good enough to be a “real engineer” and should only write enough code to demonstrate concepts. To learn Python, I ended up listening to podcasts and reading blogs, absorbing not just the technical content, but the sense that there were real people behind the languages and not some savant engineering genius (though there certainly are a lot of those as well), people just like me. It kept me going when I might otherwise have felt lost and stupid. Over the last decade, I’ve mostly written Python, but also some JavaScript and SQL recently. I’ve learned/written some Ruby, PHP, but none of them really stuck. Python was always good enough if not better and when prototyping an idea, I always reached for Python first.

It was only at Numeracy that I finally learned a new language. Numeracy’s backend was written in golang1 and as part of the aquistion, I’ve moved into engineering and spend a fair amount of time writing go and unlike other languages, I’m likely to continue learning and using Go.

Go distinguishes itself in two respects: static typing and concurrency. Static typing requires more of an upfront investment, but as a new engineer coming abroad a massive codebase that has been through several pivots, it’s a godsend. Concurrency, on the other hand, is just straight-up better. Python’s concurrency story always required an understanding of the GIL and required more memory. When dealing with massive currency (c10k problem), memory usage matters.

I still don’t think Golang will be my first instinct: my first personal project in Go has gone in fits and starts. Having to plan out types when you’re still sketching out the idea feels unnatural. Understanding how concurrency works in Go is invaluable; so many of the problems I assumed should be solved with worker queues might better be solved with concurrency. It’s provided me an entirely new and interesting tool to reach for when solving that slice of problem.

  1. Why write a BI tool in Golang? Numeracy leverages Go’s currency in attaining response times near psql or other native database clients. Most BI tools are written with single-threaded languages. A naïve implementation will first store it in a document database before returning them to the web client. When a query result returns hundreds of thousands of rows, this can add seconds to your response times. When iterating on queries (where the first hundred rows might reveal a mistake), this can make a significant difference. On top of that, Numeracy provided summary histogram on each of the columns alongside the results. Providing these scans in near-real time also benefited from using Go.