I decided (again) to become more proficient in the Go programming language (golang) and actually get something done.

Programming in a language is much like learning to play the guitar or working out. The more consistently you do it, the better you get at it. This ignores, of course, that you actually need to pay some attention to what you’re doing and how you’re doing it, but routine does help a lot.

To this end, I created a self goal to learn and use Go every day for 30 days, which will be the “Go challenge” in this blog.

This is done after day 1 (even though day 2 remains unfulfilled). Yesterday, I restarted Alex Edward’s “Let’s Go” book, a Go community favorite. It’s not my first time picking up the book, in fact last time I completed half of it. But I feel the need to start over, since it’s been a while.

So, before I talk a bit about yesterday, here are the base rules for the challenge:

  • Every consecutive day, I need to create some meaningful code for at least an hour (though 50 minutes is admissible if there’s a good reason for it);
  • By meaningful code, I mean it can’t be hello world. It’s either following part of the “Let’s Go” book or creating some (working) piece of software;
  • The day ends when I go to bed, not midnight;
  • The daily counter is reset if one day is skipped;
  • Since I’m an adult with adult stuff happening, the hour may be split in smaller chunks, up to a reasonable limit and as long as it makes sense;

“What’s the goal”, you may ask. My answer is both “for fun” and “for profit”. We are using more and more tools designed in Go at work, I’d say the language has little to prove nowadays. Java is the breakfast, lunch and dinner at my workplace, and it has it’s perks, namely that it’s a very common and popular language. But sometimes you need some small, compiled piece of software, to distribute among colleagues, or you need to run 50 instances of it without eating so much RAM that your neighbors make a nutritionist appointment for you. Java has been growing in that last front but I feel it’s at the cost of providing workarounds. Python is python. I love it but lord help me when I have to package it… I’m still in love with FastAPI, and I’m still working on it almost daily, but I have to broaden my horizons.

About yesterday:

I’m in chapter 2, where you really start to get your hands dirty with code. Even though I have made working software in Go (I have a Fiber framework project running in production at work for about 7 months and some small utility software), I’m still amazed by what can be achieved just using the standard library. For those unfamiliar with the language, you can set up a working webserver that serves static files and generated templates using solely the standard library. When I started, having previous experience with Jinja (python), the templating engine felt somewhat clunky, though that has changed and I’ve come to appreciate it. For python, you’d reasonably need a framework like flask (plus Jinja) or django to get the same functionality, and especially with django, that framework is going to become part of your application, with a lot of decisions made for you and a lot of magic built in, for better or worse. Maintainability concerns also arise, the moment you import a package.

The compiling speed is also a great selling point. Running small apps from source is as or less painful than doing the same in python.

If I had to complain about something, it would be the default servemux (the “thing” that routes a request to a certain endpoint to a certain handler/controller). I wish it had more features that would provide a good framework for a REST API without having to resort to third party routers. It’s not a big deal, and you can get far with the default servemux without trouble if you don’t adhere to REST specifications, and there are a lot of custom servemuxes to pick from on the web.

Another thing that might be annoying is that you do need some boilerplate to get a standard library app up to production standards. It’s not terrible and you can have it pre-baked and ready for all projects but it’s there.

Anyway, this challenge is more about code than it is about writing about code (though I’m taking it as an opportunity to get some blogging done). I hope you’ll find my insights interesting and come back for the next update!