Why?

I wanted to learn the Go programming language, and my preferred way to learn a new language is to use it on some open-source project¹.

In the past I studied new programming languages to “broaden my programming horizons”; to add better, more sophisticated tools to my toolbox: new paradigms, concurrency models, type systems. Because I never used it in college and never needed it for work, and because it seemed to lack this novelty factor, I never got around to trying Go.

But, over the last few years, there has been a shift in how I assign value to technology. I don’t underestimate the value of trying different things and broadening my horizons, but I find the choice of sophisticated technology hard to justify for most real-world projects: in the long term, the complexity they add outweighs the value they bring. In turn, I became less and less enthusiastic about studying technology that I don’t expect to ever apply —that I wouldn’t dare to inflict— to the real world.

The very reason why I had avoided Go in the past, now compelled me to give it a try: Go seemed to be an unpretentious, boring language —and I mean that as a compliment—, one that combined many of the features I came to value (or miss) in other languages:

• A powerful concurrency model that’s built into the language rather than an afterthought.
• A static type system that’s neither astonishing nor bureaucratic.
• A good balance between high-level programming and performance.
• A gentle learning curve.
• Compilation to easy to distribute and operate binaries.

That’s the preconception I had about Go, having read about it but never used it. I wanted to spend some time with it because, if these presumptions turned out to be right, Go could become the obvious default for many of my future projects —and an accurate boring tech radar.

Go is famously good for building server-side software, so that was the first space I turned to when looking for project ideas. I briefly considered following the Distributed Services with Go book, but I felt that I wouldn’t get enthusiastic enough about that project to see it through to completion. More generally, I suspected that any backend-only project would turn into a useless toy I wouldn’t care for. I needed something user-facing.

Could I use Go to implement the backend of a web application, instead? That would’ve made sense, but I was just coming out of working on a medium-sized web application²; I knew too well that much of the effort in such a project would go into the front end, and I needed a break from that.

What else, then? Other than servers, Go is known to be good at command-line applications. I enjoy working on CLIs; they challenge me to design and reason about the user experience without most of the graphical interface struggle. A CLI app sounded promising.

I read somewhere that a blog is the ideal learning project for software developers: it can get as simple or as complex as you want, it exposes you to the entire web stack, from server setup to UI design, and when it’s working you are encouraged to write about something (most likely about setting up a blog).

That notion, projected into the CLI application space, yields a static site generator: a command-line tool to set up blogs. For several reasons, this seemed like the kind of project I was looking for:

• I knew static site generators were useful because I’d been using one (Jekyll) for years.
• Moreover, since I had recently rewritten my blog from scratch, I knew what I’d like to reproduce and what to change from Jekyll, and I knew that, at least on a first look, it was about the project size I was looking for: not so small as to be boring, not so big as to get out of hand.
• I knew that it was a feasible Go project because one of the most popular static site generators, Hugo, is written in Go.

Assuming I would implement the local serving functionality (i.e. jekyll serve), I could even go beyond the file manipulation tasks and touch on some of the concurrency and HTTP features of Go.

Working on a site generator also meant that I could use the project to generate its own documentation and potentially to keep a development blog; to “dogfood”, using the software myself as I was building it.

With that reasoning, I arrived at a project idea that seemed appropriate for my goals, feasible, and interesting. This was enough to give me the first push to start working on it, but I still needed to outline the user interface and the project plan before a few more of the pieces fell into place. I’ll get to that next time.