An Economics Major Learns Go

July 5th, 2019

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 golang¹ 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.