Learning Go the 'right' Way August 9, 2025 on Erick's blog

While working on a larger project, I was in need of a GUI library. I needed it to be cross-platform (Windows, Linux, and Android, if possible). My main programming language is C, with Python, and a few other scripting languages (Lua, bash) on the side, so building a cross-platform app using those was gonna be a slow process, either development-wise (C), or runtime-wise (Python).

Instead of just giving up and doing it on Python, or taking the bullet and doing it on Qt, and upping my C++ skills, which are abysmal, I decided to pick a newer, compiled language. That’s how I decided on Fyne and the Go programming Language, or Golang, for short.

The language itself doesn’t look particularly difficult. It has the right amount of OOP-ish concepts to feel interested, but not that many to start questioning my sanity (I’m looking at you C++ and Java). It also feels, as advertised, like a C language for a modern audience.

So with that, I started by going on the golang so called ’tour’ and installing the go package in my Linux system.

After going through around 70% the tour, I realized It was probably enough to give Fyne a try. In short, I think I was mistaken. While I was able to understand the examples and write some of the things I wanted, I felt I wasn’t really writing idiomatic Go. Mainly, I think, that’s because I hadn’t really written any code using the language, and I jump straight out of a simpler language, and a very different use case, into a very Library-centric kind of project. That’s the reason why I decided to take a step back from Fyne for a minute and restart my Go adventure with a simpler project, from the ground up.

I was thinking long and hard about what could be the ideal project in order to understand the language’s details and grasp its idiosyncracies. I decided on making a CLI application, that way I’d need to deal with most libraries, like string manipulation, IO, files, and other OS related functionality, like process forking, threads, signals, etc. I figured that making something that was already well defined and feature complete was the smartest idea. Mainly, because it would not become an additional task to be figured out by me before even writing the first line of code.

Here are some of the ideas I had in mind:

There were also other similar ideas, like rewriting which(1), which was too easy, or unzip, which might be too large for it to be ideal. At the end, I decided to do coreutils. It looks like the perfect project for this kind of situation. The main reasons I could think of were the following:

  1. It is cleanly divided in shorter tasks. So going at it daily will be straightforward and satisfying enough.
  2. The tasks themselves vary in difficulty. Some commands are quite easy to implement(true), while others might require a bit more knowledge and thought put into it(stty).
  3. Besides the main task of learning Go, writing these applications gives you a better understanding of a *nix system1, which is always a nice bonus.

So, with that cleared, I’ll start this mini-project, at least while I got the free time or until I feel that my grasp of Go programming is good enough.

I’ll try to keep blogging about this in the following days.

  1. It is as good of an opportunity as any to read the POSIX standard. ↩︎