My 2024 Coding Journey

blog@yourbrowser ~ $ cd /home/blog ^C
blog@yourbrowser ~ $ cd /posts/personal
blog@yourbrowser ~ $ blog --date

January 01, 2025

blog@yourbrowser ~ $ blog --author

Niklas Koll

blog@yourbrowser ~ $ blog --time

9 minute read

blog@yourbrowser ~ $ blog --content

We have a New Year and as every good, regular posting (wink) blogger, there has to be an article about the just past year.

2024 was a year filled with a lot of personal development in terms of new languages and technologies I found and learned to love, as well as some shifts in the way I do my work. This Article will be a rundown of the things I found important or interesting. It will also be used as a memorial kind of thing, to look back at next year and hopefully see another noteworthy improvement of my programming skills.

Languages

This year was filled with tons of new languages I found out about, as well as quite a few I tried my hands on. To list some of them:

I already did a few things in C on an Arduino and other Microcontrollers, but I did my first real project in C++, Japr. It is not the biggest or prettiest project I have, but it is in C++, it uses the mighty Qt-Framework and solved something interesting.

Zig must be my new favourite programming language. It was my entry into real memory management, a lot of new concepts surrounding that like the distinction between the Stack and the Heap, Ownership of Memory, Immutability first and Compile-Time Execution. Zig was incredibly fun learning, it doesn’t have as steep of a learning curve as other non-garbage-collected languages, it saves you from a lot of footguns and was all in all just a good experience. Oh, the best part of Zig has to be the build-system, the infamous build.zig file. I already have a post about it, where I go more into detail. I seriously recommend learning Zig to anyone, who has to do any kind of lower level programming, or wants to get into it. If you have knowledge in C/C++, learning Zig will be a breeze. If not, it will just be like any other language. I also recommend the unofficial Discord-Channel, the people there are amazing and very welcoming to newcomers.

Golang is a language, that was on my list for quite some time, but I never had the chance to really give it a go (pun intended). I used Advent-of-Code as an Excuse to try it out, and after a few confusion about project structure, I found it almost boringly easy to learn. The syntax and language constructs are so simple that you literally can learn enough of Golang in a Weekend, to start a real project. I haven’t gotten around to build a big project in it, but I will do that in 2025, hopefully, possibly, maybe.

I already had some small exposure to Lua on a long-running project of mine, where I embedded the Lua Runtime into an embedded program running on the ESP32. But this year was all in the name of configuration. Specifically Neovim configuration. I tried Neovim, made my own configuration, fell in love with terminal-based workflows and learned a few things about Lua. Neovim can be configured and customized using Lua Code in some very specific and detailed ways. I even wrote my own Neovim Plugin in Lua, which I use on a daily basis.

Elixir is an interesting one, because it is the first functional language I tried out. I used 2023s Advent-of-Code to try it out, and I haven’t gotten around to a big project using Elixir yet. BUT, even with just that limited time, I loved the elegance of functional programming. Elixir is one of the easier functional languages to learn, coming from procedural programming. Even if I have not yet made something notable in Elixir, I sure as hell let it influence my programming style in other languages. I started using more functional-like thinking and even used some patterns in PHP to have a more Pipeline-like Data processing. I think, everyone should at least try a language in a different paradigm than they usual use.

Nix is sort of an odd language in this list, because I didn’t really learn the language, as it is not a General Purpose language. Nix is a Domain-Specific-Language, designed to be used for the Nix-Package-Manager. It is used to write the so called “Derivations”, that make up the Nix Ecosystem. But later in this articale, I go more into detail on how I started using it.

Besides these languages I specifically tried out, there is also a whole new Universe of lesser known languages that I found out. It surprised me, just how many programming languages exist already, and still get created and refined everyday. I want to look into some more programming languages and try out a few in the coming year. I think, trying out different languages, using different ideas is purely beneficial as it gives you a more divers toolset of ideas and concepts to reach for, even in other languages. For example, some of the functional ideas in Elixir can be applied in PHP, thinking about Memory Management makes you think about efficiency in GCed Languages and so on.

Tools

Here are some of the tools I started using and embracing in 2024:

Terminals are almost inevitable as a Software Developer. At some point, everyone at least touched a terminal once and likely got scared. A blank, black Screen, with white text, telling you your username and a blinking Cursor. That might induce some anxiety in the untrained, I felt the same when I first looked at a Terminal. But in 2024 I was already confident using the Terminal and move towards more and more Terminal usage. I found, that using a Terminal is surprisingly fun for me. With a bit of practice, I also feel faster than using the classic GUI for some tasks. This was made even clearer once I got more familiar with Neovim. Speaking of…

My new favourite way of coding: Neovim! I tried it out, because I wanted to use Zig, but I could not, by any chance possible, get comfortable using VSCode. It took quite a long time to really get up to speed with the Modal nature of Neovim/Vim and all the Motions you can execute, but with a lot of patience, it started to get fun, zipping through my code, jumping around exactly where I want to jump to, and all that without even touching a mouse. Another benefit for me personally was the simpler UI. My personal Neovim configuration has a so called “Status-Bar”, at the bottom of the screen, which shows me some information about the file, the mode I am in, if my changes are saved to disk, how many unsaved files (akychually Buffers to use the correct Vim Term) I currently have opened and some other details. All this information takes up only a single line of text at the bottom. Other than that, I pretty much only see my code and nothing else. This feels very nice, as there is nothing taking up my precious screenspace. I can focus completely on writing the shittiest code one can write.

I already talked about Nix the Language, here comes some more details about how I use Nix the Package Manager. I exclusively use a feature called “Flakes” for my projects. It is deemed experimental by the Nix Team, as in, it’s API, Structure and other Stuff is subject to change, but it has been the same for quite some time and personally for me it is all I need and could ever want for a project based package management. Nix has a lot to offer. Like, a lot a lot. I use only a small subset of what is possible, but I try to get more into the nitty gritty details of the Ecosystem and get more familiar with it. Having said all that, I use Nix Flakes for project based package management. It gives me the ability to keep my system very thin and clean, with only the dependencies to be installed globally, that I need outside of projects. All system dependencies like packages, libraries, CLI-Tools, even Language Servers for Neovim can all be installed on a project specific configuration using a Flake. You then just pop into a “DevShell”, specified in the Flake, and Nix manages everything else for you. You get a Shell with all Tools and Dependencies you need, and everybody who also uses Nix can get pretty much the exact same shell by just cloning the project and calling nix develop. As soon as you exit the shell, all dependencies are removed and practically don’t exist on your system anymore. Technically, it still lies in the Nix Store, but you can clean that up using nix-collect-garbage, which removes everything you are not actively using right now. Even if you just removed everything, you can just navigate to the project, get into your DevShell and all dependencies with the exact same version are redownloaded. There is so much more and I love the concept of Nix, but I still just dipped my toes into it. I will continue to use it and get more familiar with it, so I can use the full potential of Nix.

Direnv is something I just started using and plays nicely with Nix. It allows to define Environment Variables and other Shell stuff and a Directory basis and loads it automatically upon entering the directory. When leaving the directory, the Shell Environment gets unloaded and the previous Shell is restored. Is has some functions to work together with Nix. It automatically loads the DevShell specified in the Flake. This, together with Nix Flakes, makes me define all my dependencies and system libraries on a per directory basis. It works almost magically. I enter a directory and have some libraries installed. I switch to a different directory, I have other libraries installed.

Projects

I had some fun projects this year. A few notable examples:

I am especially proud of Flow. I made a few Posts about it already, with likely even more coming. I am still developing it, so there are a lot of changes still coming.

All of these projects taught me something else. For Japr, I had to learn the basics of the Qt Framework and how to make a kinda-gui-kinda-not App within the constraints of the Framework. Crafting Interpreters was an incredibly interesting journey, which gave me a lot of insights into how Languages are designed and Interpreters work. With Flow, I tried to apply these lessons I learned and design my own language. ZS made me get more into how Unix-Filesystems work and how to do interact with libc from Zig. Ignorer.nvim taught me a bit on how to do more advanced stuff with Neovim and how to further customize and optimize my Workflow.

Conclusion

I evolved a lot this year. I learned many things, many different technologies. I improved my workflow, I have more fun coding and all in all am very proud of what I did this year. I look forward into my journey as a Software Developer and what I will learn in the coming year.

# jump to top