I did the Advent of Code in Golang last month and overall found it to be an excellent experience. The quality of the problems was good, although some days were too trivial, and it was a great learning experience for getting more familiar with a language – in my case, Go.

(I did about half of the advent before life happened, but you can check out the solutions to the first half here!)

One of the main takeaways it left me with was how ill-suited Go is in some ways for solving code problems like these. Parsing input and the lack of built-in functions that are standard in other languages like Python wore on me pretty quickly. For example, Go’s STL doesn’t have a lot in the way of collections; if you want a queue, you have to either write your own, or use somebody else’s from Github. I also found myself missing list functions, especially coming from C#.

Rob Pike, one of the creators of Go, gave a talk about the simplicity of Go that notes the lack of features compared to other languages. Pike points out that Go was designed to be a “clean procedural language designed for scalable cloud software”, and as such was built with a minimal set of features to accomplish that goal.

“Uncle Bob”, or Robert C. Martin, of Agile Software Development and Clean Code fame, argued against the reckless use of overly-complex frameworks and languages in “Make the Magic Go Away“. His view seems to be similar to that of the designers of Go.

 Perhaps you should just write the little bit of code that you need, instead of importing thousands and thousands of lines into your project. Lines that you didn’t write. Lines that you don’t control. Lines that you probably shouldn’t be putting a whole lot of trust in.

Now, I have a computer science education. I can certainly write my own libraries if needed. And I love avoiding bloat in a codebase. That being said, spending time reinventing the wheel is not always the best option either.

As with any other language, Go is simply a tool. It’s not going to be the best language for every situation; it’s awesome for concurrent tasks and I know a lot of SREs who love it for their work. But for next year’s Advent of Code, I will likely be solving the problems using a language more suited to that kind of problem-solving.