It’s been a while since I have written one of these. There’s definitely a cadence to these. That cadence would be something between once and thrice a year. 2024 will have to make with just one. I have spent a bit of time understanding the ggwave project, which allows for sending data over sound. It’s not an extremely complicated protocol. I think the most difficult part to understand is the Reed-Solomon error correction, which is still something I have not delved deep into. I have first started by understanding Fourier Transform well. This started with a Jupyter notebook, but I have quickly moved to using Marimo. You can find my repo here, but don’t expect it to be polished and guests friendly. My actual Data Over Sound project lives here. It aims at implementing the ggwave protocol, on ESP32. It’s not even close to being done. I have written my own comments system for this website. I have realized that the most important part are the actual comments, the data, snapshot of someone’s thoughts, captured as text. My goal was to create an interface for you to be able to send me these thoughts and a system to store them. At this point I might be describing email. Where a comment system differs is that each subset of that data references a certain piece of content on the internet, and the same content on the internet has to display that data. You could argue that a comment system should support editing one’s comments, replying to others’ comments, browser admin interface and upvoting/downvoting system. I would argue that none of these are core functionality. Anyways, defining a comment system in with these strict requirements, I have written a super simple Python Flask + HTMX app, with less than 500 lines of code. The plan was to re-write it in Nim (I really like Python but I do not like maintaining Python code), but I have realized it’s a perfect opportunity to learn some Zig, and proceeded with that idea. I hope to move to using Zig version in the next few months. Let’s talk Zig then. I have been interested in the language for a while, with little time to actually try it. That hasn’t change much, because time is still sparse. I have however managed to blink an LED of a Bluepill with a simple Zig application - zig-pill. It’s definitely a messy first attempt that needs cleaning up. If you’re interested in the topic take a look at Zig Embedded Group. I have opted for not using any dependencies at this point, but their projects like MicroZig can provide some inspiration or help. The superhtml project, written in Zig, has been a great find. I’m using it for checking this website’s HTML for any errors and for reformatting the HTML files. It can run as a LSP server, which means I can see issues with my HTML while I’m writing it. The there’s ghostty - a terminal emulator written in Zig. I have not tried it yet, since the publicly available version 1.0 comes out in December 2024. If you’d like to see what it can do check out this YouTube video. The shaders support looks super fun. Browsing Hacker News I have stumbled on this post, written by Gavin D. Howard. It talks about weaknesses of tools like CMake - meta build systems. He proceeds to explain how end-to-end build systems can provide a better developer experience. You might be have seen the CMake + ninja combo. CMake configures the project and generates the ninja compatible files, ninja executes the build steps. End-to-end build system handles both steps. That led me to discovering Rig Build System - Gavin’s attempt at implementing an end-to-end build system. While CMake is a popular choice, it’s not particularly liked (single example but if you google around the sentiment leans towards a negative one). It requires a lot of work to set up a project correctly. It’s a dense system, full of features and terminology. New languages bring their own build systems, but there’s an argument to have a separate system, which is language agnostic, and can be used in all your projects. Rig is an interesting attempt at doing just that, while avoiding CMake’s mistakes. Rig uses Gavin’s Yao programming language. Currently it’s a very simple language, and according to Gavin, one will be able to restrict the language to use a subset of its features (I can’t find his exact post that mentions that). Read more about Yao. I have tried Rig in one of my embedded projects. It’s not a particularly complicated project: libopencm3 HAL with a FreeRTOS and it doesn’t push Rig to its limits. The project itself deserves some attention. Gavin is great when it comes to feedback, so reach out to him if you’re stuck or have some suggestions. While we’re on the topic of build systems, let’s talk xmake. It’s a C/C++ build system and a package manager which uses Lua. It’s not a very versatile tool, but there’s a certain type of project that I think it fits quite well for. For me that project is a small 3D OpenGL engine. It depends on SDL and libepoxy. Both of these dependencies are managed by xmake, meaning it’s responsible for pulling it from the internet and correctly linking it into my project. I still feel intimidated by xmake, but since it’s using Lua, one can install it and modify its script files in the ~/.local/share/xmake. Adding some prints in these files helped me to understand xmake a bit more. I can’t tell exactly if I have reached a certain level of maturity, in the field of software development, which allows me to understand the space better and see new trends, or is it a unique time, in recent history, for new programming languages and new initiatives. We have a lot of new, interesting languages: Rust, Zig, Odin, Nim. These are the ones I’m personally interested in. It’s incredible to see very small projects grow organically, and explore new ideas. Rust, because of being the most mature one, is the most popular new, systems programming language. Personally I find it less interesting than Zig. I feel Rust addresses problems often seen in the C++ school of thought, while Zig chooses to take a step back and follow a path where these problems tend not to even pop up. The biggest example would be the borrow checker. It addresses the problem of dynamic memory management, but it’s a difficult tool to wield. I tend to be more convinced by the Zig’s attempt at solving this issue: custom allocators with a bit of syntactic sugar like defer and errdefer. I do admit that my way of thinking might be skewed because I spend more time writing C than anything else. There’s an idea of writing a simple game, using Odin brewing in my head, because I find GingerBill’s thoughts on programming quite resonating. It’s a great time to write software, not because you can avoid it, by using AI, but because you can learn from many talented minds. Every new language tells you a story of what, people more experienced than you, find important in order to push us towards more reliable, more performant software. Even if you don’t want to use these new languages, you can get a new perspective on the one you’re already using. DRAKON is an interesting artifact of time. It’s an algorithmic visual programming system. I’m not much interested in generating code from a its visual representation, but there’s something about it that I find pleasant, when trying to visualize an already existing code. I used it lately in a few cases, where I had to communicate something with the team, and I think it was easy for everyone to follow what’s happening in that diagram. Communication is important but difficult, especially when we talk about code. It’s very difficult to explain how a system of moderate complexity works, without having some visual aid. DRAKON seems to fill that role, for me, well. Unfortunately, the web editor drakonhub.com shuts down on the 1st of December 2024. I recommend you try DrakonHub for desktop. I was thining about getting a laser cutter for a while. Roly Automation stood out with their LaserMATIC Mk2. Seems to be a great diode laser machine but for the time being I have decided to buy a K40+ from OMTech. It’s a 40W CO2 laser. It’s one of these generic chinese products, sold by many different vendors. Its build quality is definitely worse than LaserMATIC’s but it’s more powerful and half of the price. I have payed less than 650 USD, including a Lightburn license. One more thing I wanted to give a shout out to is linkhut. I’m a Pocket hoarder, but I’m unsure about the platforms future. I also prefer linkhut’s more minimalistic design and its API. If need be, its trivial to export my data from linkhut and self-host it. 2024 has been a difficult time for me, when it comes to building. It’s not always a problem of time but also one of priorities. I hope to make 2025 more focused on what really resonates with me… despite that being a very long list.