Learning Golang

This year marked a significant shift in my professional journey as I transitioned to a new team, where Go stands as the primary programming language. As someone who hadn't previously engaged with Go, these past months have been a deeply immersive learning experience. In this post I will briefly share some of my thoughts about this process.

It's particularly pertinent to consider this journey amidst the current, somewhat chaotic, integration of AI into every facet of software development. It offers a valuable opportunity to pause and reflect on what it truly means to acquire new skills in an era where some people claim AI makes all skills obsolete.

My Learning Trajectory 

My approach to learning any new subject, especially a programming language, typically involves a structured path. While often a single video course suffices, I added a few more steps in this case. I began with the official language tutorial, followed by a full video course, and, finally, embarked on a series of personal projects to solidify my understanding.

Official Tutorial 

The initial step involved working through the tutorials on the official Go programming language website. This proved effective for environment setup and familiarizing myself with the core code-build-run cycle. My exploration here was primarily foundational, extending only slightly beyond the "Hello World" scope.

Udemy Course 

After gaining a basic grasp of project bootstrapping, I sought a more in-depth, structured resource. For years, Udemy has been my go-to platform for professional development in software. Thankfully, I found out that Maximilian Schwarzmüller offered a "The Complete Guide" course covering the language. Having completed several of his courses previously, I had high confidence in the quality, and I wasn't disappointed. Though perhaps less comprehensive than some of his other offerings, it provided a robust foundation in the language's fundamental concepts and constructs.

Projects 

While a thorough video course usually equips me sufficiently, in this instance, I felt the need for more. This followed from a confluence of factors: Go not being my immediate choice for personal applications, its less-than-intuitive aspects, and the workplace emphasis on AI-generated code over manual development. All of this motivated me to deepen my learning through practical application.

That is when I created a list of 10 application projects to develop in the language, which would progressively make me exercise more and more complex concepts. I have wanted to create such a "curriculum" for a long time now, so this was the perfect opportunity to do so. I tried to frame the projects in a way that could be used for almost any language, and put the list in a public Github repository. I also wrote a blog post about it.

Challenges 

AI

Artificial Intelligence undeniably offers substantial productivity gains in our field. However, the prevailing directive from upper management to uncritically deploy AI-generated code introduces significant challenges, particularly concerning knowledge acquisition and retention.

When your only incentive is to push out as much code as possible, as quickly as possible, it is easy to not put the effort (and time) into learning new things. If it seems to mostly work most of the times for the things you already know, you end up assuming it will also work when you do not know enough to make a judgement on what it is producing. But the catch here is in the "most" and "mostly" part: there are very significant and problematic cases in which you need to use your judgement to override something the AI made. If you are using AI to ship something in a language you do not know, you are not able to do that.

My approach has been to use AI as dictated while at work, and while creating things for personal use that I already know deeply how they work. But to avoid as much as possible relying on it while I am learning something new - I try to write all new code by myself, researching when I do not know how to do something, and only resorting to generated code when I am at an absolute loss. I then use generative AI models to analyse and evaluate my final implementation, asking it to give tips about best practices and where I could improve. I believe this approach not only preserves the learning benefits of a pre-AI era but also augments them, maximizing the value derived from this new technology. It is a shame that it is so hard to communicate this to the highest level of management at companies, these days.

Overlapping 

Another challenge I found is the fact that I do not see myself using Go for my personal projects. The language seems to overlap a lot with other languages (mostly Java, also some Python and JavaScript) that I already master and that work perfectly fine for me. I feel like I have to put conscious effort to choose Go as the main language for any new project I might start, and I am not sure how sustainable this is in the long run.

Thoughts So Far 

Overall, I find Go a pleasant language to work with and considerably simpler to learn than I anticipated. While it is definitely not my favorite language (not by a long shot), and I don't foresee continued investment in it beyond my current professional requirements, it effectively serves its purpose, generating optimized executables with minimal overhead.

Error Handling Code Everywhere

One aspect of the language that I find slightly weird is how much error handling code it needs. I do not know if this is just a skill/experience issue, but having seen code for fairly seasoned Go developers I am inclined to conclude that it really is intrinsic to the language. It feels like half of every Go source code file I read consists of "if err != nil".

While I do appreciate the safety that this might bring to programs, it still makes the code feel slightly uglier than in other languages, to me.

Dependency management

The only other point that I find disconcerting is Go's dependency management mechanism. Coming from a Java and JavaScript background, I am used to having solid, unambiguous and strict manners of declaring and managing your dependencies. Go's approach feels very idiosyncratic and flaky, and at least once per month I have very experienced Go developers telling me to run some arcane command to "just fix your vendoring" without being able to explain what the command is actually doing.