DEV Community: Dayvster 🌊

My Problem With Omarchy Is What I Like About Arch

Dayvster 🌊 — Thu, 08 Oct 2026 09:03:40 +0000

The things I like most about using Arch are also the things people keep trying to save me from. Setting something up, getting it wrong, reading the documentation and eventually understanding why it works. I didn't come to Linux just to get a different desktop. I wanted to know what my computer was doing.

So when somebody packages that whole experience into a ready-made setup, I understand the appeal. But when the next promise is that an AI can handle the things I don't understand, I start wondering what kind of relationship with my computer I'm being offered. I wanted to become more capable of looking after it myself.

That is my problem with Omarchy. It looks good. Clearly a lot of work has gone into making the pieces fit together. But I think its pitch puts too much value on what I can avoid learning and too little on what I could learn to control. Making those decisions myself was a large part of why I wanted Arch in the first place.

Yes, this is going to be an Arch user explaining why he likes configuring things. You had fair warning from the title.

I've held off on writing this for a while because I really don't want to be the guy greeting someone who's excited about Linux with "you're doing it wrong." I like the momentum Omarchy has around bringing new people in. If someone installs it, enjoys it and finally feels comfortable using Linux, I'm happy about that. The last thing I want is to contribute to the negativity that makes them wonder why they bothered.

So if Omarchy is how you got here, welcome. I hope you stick around. What I want to make a case for is taking the next step, getting curious about the system you've installed and finding out how much of it you can make your own. That's the part I enjoy most, and I'd hate for the promise of an easy setup to make it sound like something worth avoiding.

I Wanted to Know Why

There is something satisfying about looking at your setup and knowing why it's like that. You picked the window manager. You know where the keybindings live. That slightly odd behaviour exists because you changed something to suit the way you work, and you remember what you changed.

It doesn't have to be impressive. Nobody else needs to want your configuration. You understand it, and when you want it to behave differently you have some idea of where to start.

That matters more to me than having a desktop that looks good in a screenshot. I like a beautiful desktop too, obviously, I've spent enough time on zenkai's themes to lose any right to pretend otherwise. But I want to understand the thing underneath it.

Some of that understanding comes from curiosity. Some comes from a much less noble place: something annoys you enough that you finally go and find out how to change it. You read about an option you didn't know existed, find the file that controls it, and suddenly one more part of the system makes sense.

You might not have set out to learn anything that evening. You just wanted your shortcut to work. But now you know something you can use the next time you have a problem.

A Finished Desktop Is Someone Else's Starting Point

Omarchy's own pitch is a working system with the tools and details already chosen for you. It also explicitly says you're free to change everything. The source is available, so I'm not going to pretend this is a locked appliance or that installing it takes away your permission to edit a configuration file.

You can use it as a starting point and learn from it. Reading a working configuration is useful. My criticism is of the direction being sold, not a claim that every Omarchy user accepts it or stops learning.

But you can also stop at the finished desktop. Everything works, the choices look reasonable, and there's no particular reason to investigate what made it work. The opportunities to learn are still available. The reasons that would have pushed you into them have become less immediate.

This is where I think Omarchy's pitch falls short. It puts a lot of emphasis on removing the setup, the decisions and the troubleshooting. Those can be frustrating, but treating them mainly as problems to eliminate undersells what you can learn from them. I'd like to see as much enthusiasm for helping people understand the system as there is for getting them past the need to understand it.

Of course someone with work to do might happily accept that tradeoff. I do too, with plenty of tools. But it is a tradeoff, and I don't think a shorter installation tells us much about how capable we'll feel when we want something the default setup didn't anticipate.

For me, though, being handed a setup where the interesting decisions have already been made can feel pretty boring, even when the result is pretty. I want to try things, disagree with the defaults and work out what I actually like. Getting to a usable desktop was never the whole project.

An opinionated desktop also means adopting somebody else's preferences before you've worked out your own. That can be helpful, but it isn't automatically simpler once you start disagreeing with those choices. Now you have to learn what the underlying tools do and how the curated setup connects them. The complexity hasn't disappeared just because you didn't encounter it during installation.

You Can Put This Together Yourself

Omarchy isn't black magic. There is real work in integrating a desktop and maintaining it for other people, and I don't want to dismiss that. But you don't have to recreate everything Omarchy ships to put together an Arch and Hyprland setup that works for you. You only need the parts you actually want.

I think that is a much more approachable project than people make it sound. Start with a working Arch installation and follow the Hyprland tutorial. Get a terminal open, configure your display and choose a few keybindings. Then add the things you need: a launcher, notifications, a bar if you want one. You don't need somebody else's entire desktop before you can start using yours.

Hardware can complicate things, and a first installation will take longer than your fifth. But choosing a terminal, changing a shortcut and adjusting a configuration file are things you can learn. You don't need years of Linux experience before you're allowed to try. A basic personal setup can be fairly straightforward; getting every colour and animation exactly how you want it is the part you can happily turn into a hobby.

And it doesn't have to look like anybody else's. Maybe you don't want a bar. Maybe you want different shortcuts, fewer animations or a launcher that behaves differently. You get to make those decisions one at a time, and by the end you know why each piece is there.

That is a practical kind of ownership. When a shortcut stops working, you know where you defined it. When you want to replace a program, you know what calls it. You can keep your configuration in Git, see what you changed and go back when an experiment doesn't work out. The time you spend setting it up buys you some independence the next time you need to change it.

Convenience Can Become Dependence

For me, ownership includes being able to disagree with the people who made the tool. I want to remove something they like, keep something they don't, and fix a problem without waiting for their preferred solution. Having permission to do those things matters. Having enough understanding to actually do them is what makes that permission useful.

Omarchy doesn't have to take away the first for me to worry about the second. If every change goes through a menu or an agent, you can end up with a computer you're allowed to modify but don't really know how to investigate. When something stops working, your next step is to ask the same tool for another fix.

That can happen on a manually installed Arch system too. Copying commands you don't understand isn't magically educational because you typed them into a terminal. And a good graphical tool can explain what it's doing better than a page of unexplained shell commands. The interface isn't the deciding factor.

Imagine replacing your launcher and finding that the old one still opens from a shortcut. If you know where the binding lives and what starts the program, that's something you can investigate. If your only approach is to ask an agent to fix it, you have to trust that it finds the actual cause rather than adds another change around it. You might get the shortcut back without getting any closer to understanding your setup.

That is the loss of ownership I'm worried about. The files can still belong to you while your ability to make decisions about them depends on something else. No one has to lock you out for you to feel unable to proceed without help.

This Is the Same Argument I Keep Having About AI

In We Were Not All Terrible Developers I wrote about the idea that generating code removes the need for developers who understand it. This bothers me for the same reason. Getting a working result and learning enough to take responsibility for that result are different achievements.

Omarchy makes the connection quite directly now. Its homepage promotes using agents to troubleshoot and alter the system. That could be useful. An agent that helps you read a log, explains the relevant configuration and lets you check its reasoning could teach you plenty.

But there's another version of that interaction where you describe the problem, accept the changes and move on because it works again. Repeat that enough times and you can accumulate a lot of changes without much understanding of how they relate to one another.

And I think Omarchy leans too hard into selling that convenience. Its homepage even describes "agents that debug all issues." All issues? That is a hell of an expectation to set. I'd want to inspect what changed and test whether it addressed the cause before calling a problem solved. It's still my machine that ends up with the changes, and I still have to live with them when the first fix turns out to be incomplete.

An agent being confident doesn't help me decide whether it was right. If I can't follow the explanation or recognise an unrelated change, I'm approving work I don't understand. Having a second agent approve it doesn't give me that understanding either.

The next time something breaks, what have I learned that helps me fix it?

This is where I get frustrated with the promise that we can skip all the difficult parts. Some difficult parts are just tedious and I'm happy to automate them. Others are where you develop the ability to recognise a bad explanation, question an assumption or work out that the proposed fix has nothing to do with the problem.

You don't automatically acquire that judgement because the tool gives you a detailed answer. You develop it by working through things, checking them and sometimes finding out you were wrong. I want tools that help me do that. I get much less excited when understanding is presented as something I no longer need to bother with.

Heck, use AI to help you build your setup. Have it guide you. Ask which component handles a behaviour, which file controls it and why a particular setting would change it. Ask for a link to the documentation so you can check. Make one change, try it and see whether you understand the result before moving on.

You can literally tell it:

Help me set up Hyprland one step at a time. Explain the choices and the commands before I run them. Show me how to check each change and undo it. I want to understand my configuration, so don't just generate a complete setup for me.

That sounds like a great use of AI to me. You have something to ask when the documentation assumes knowledge you don't have yet, and you still do the work of making decisions and understanding what happened. The point is to become more capable as you go. If you've finished the setup and can explain how to change it yourself, you've gained more than a nice desktop.

Let the Convenience Be Optional

I use Qt for zenkai because I don't want to write a GUI toolkit. But when I needed to understand why the launcher was slow, I had to look into what Qt was doing. The abstraction saved me work. It didn't excuse me from understanding the behaviour my application depended on.

That's what I want from my desktop too. Help me get started, but leave me better equipped to take over. A menu could show me the configuration it edits. An agent could explain a proposed change before applying it and show me how to verify it afterwards. Documentation could make replacing the default tools feel like an ordinary thing to do.

These are the things I'd put at the centre of the pitch. Being able to stop relying on a convenience is a feature worth selling. I want to hear that I can learn to manage my own system, not just that there's always another thing available to manage it for me.

If the only progress we celebrate is how much knowledge a tool lets us avoid, eventually the person trying to understand their computer starts looking like they're wasting time. I think that's a bad direction for Linux, and AI makes it very easy to keep moving in that direction without noticing what we've given up.

What I Want From Linux

I want Omarchy's newcomers to stay. I also want them to discover that the system underneath the presentation is within their reach. They can read the configuration, replace the launcher, change the shortcuts and build something that suits them better. They don't need to wait until they're experts to start becoming more independent.

Whether Omarchy encourages that or makes it feel unnecessary is what will decide how I feel about its contribution to Linux. Bringing people in is good. Teaching them to depend on an agent for every unfamiliar problem would be a poor follow-up.

So yes, I am critical of Omarchy and the AI pitch around it. I want more than a machine that does what I ask as long as the defaults and the agent cooperate. I want to understand enough to take over when they don't.

I chose Linux because I wanted that control. A prettier way to delegate it isn't what I was looking for.

Thank you for your time and patience reading this article

zenkai: The App Launcher I Wrote Because I Wanted Something Fast and Beautiful

Dayvster 🌊 — Fri, 02 Oct 2026 09:47:37 +0000

If you only came here to try it, grab it at zenkai-launcher.netlify.app and the source is on GitHub. The rest of this is about why it ended up built the way it is.

Every few months I install another app launcher, convince myself this is the one, and then about a week or so later I uninstall it because something small irritates me or it cannot do what I want it to do. After repeating this process about a dozen times, I finally gave up looking and wrote my own.

I have always struggled with naming things and this project was no exception. After an embarrassingly long time I settled on Zenkai, which comes from my childhood obsession, Dragon Ball. "Zenkai" is a massive power up that a Saiyan obtains after a difficult battle, what a perfect name, because that is exactly the vision I had for this project. I wanted it stronger, faster and more performant after every single iteration. I wanted to dive deep into performance optimisation rabbit holes where I spend hours on something that maybe shaves off 20ms or so. I wanted this to be a part time hobby.

I also wanted it to be cross-platform, because I use Linux and as any good Arch Linux user (BTW!!) I have to have a customizable performant launcher. For work I use macOS and while the native launcher there is great, I wanted to have the same experience on both systems. Windows I will be honest, I only occasionally use when I have to, so I would be lying if I said it was a high priority. Plus, Windows is pretty challenging to make a launcher for, but more on that later!

I got all 3 systems working and fully supported.

I also wanted it to be fast and beautiful, because I wanted to use it every single day and I wanted to enjoy using it. I wanted to be able to press a hotkey, type two letters, and have the thing I wanted already highlighted, hit enter, and have the launcher gone before I had even registered that it was ever there.

That is the whole idea, and so I started building it. The first choice I had to make was Language and GUI framework. I chose Zig and Qt6!

Zenkai Uses QT and Zig

I have been developing in Zig for a while now. I love the language, I love the simplicity that you can manually scale into complexity if you want to. Zig feels like C, it looks like C, but with sane memory management tools, but without a compiler that throws a hissy fit if you do not handle every single potential memory issue under the sun. It trusts you to be a craftsman, and it trusts you to know what you are doing. It is a language that does not get in your way, and it is a language that I can trust to be fast and efficient.

It is as if someone handed you a well-sorted professional toolbox.

Qt I did not choose on principle, I chose because I have used it before. I have shipped Qt applications professionally, I like its widget set, I like that you can make it look genuinely beautiful instead of the usual grey business-tool look that everything ends up as, and it is cross-platform. Zig I chose because I love it and it fits how I think, manual memory with sane defaults and a standard library that actually helps. So that is the entire strategic decision and it is not a particularly clever one. I picked the two things I already loved and hoped the rest would sort itself out.

Zenkai Is Fast

I have been obsessed with performance for as long as I can remember. Usually there is no room for it, because whatever you are working on belongs to somebody else or somebody is eagerly waiting for it, there is a deadline, and spending a week shaving 40ms off a startup path makes you a difficult person to work with. zenkai is mine and more than that I took on the project as a hobby and not a clear goal or product that is supposed to make me money. Which means nobody is waiting on it and nothing is going to break if I spend three days on something that makes it 15ms faster. For the first time in forever I could indulge my performance obsession properly, and it felt liberating.

$ zenkai --debug --quit-when-shown
[zenkai] window fully visible in 140ms

So anything under 200ms is percieved as instantaneous to a human, in zenkai's case I got it down to 140ms on my machine with plugins loaded, 100-200 apps parsed and icons loaded and rendered.

But it gets even faster, if we run it without plugins and the no-icons flag we get 20-70ms until fully interactive. That is frankly ridiculous considering it's a non native GUI application built with Qt and Zig, and it is a testament to the power of both.

What was even more shocking was how little of that startup time was mine. Breaking the startup down put everything I actually wrote at 14.75ms-20ms of the 140, and the rest was Qt building widgets and the compositor putting pixels on the screen.

All of this is very brief and I will provide a more detailed breakdown of the performance in a future post, because just that alone is a topic that deserves a longer form content type post to explain fully how I got there and what techniques I used to get there. But for now, just know that it is fast, and it is fast because I wanted it to be.

Zenkai Is Beautiful

There is this false dichotomy that you can either have a beautiful product or a fast one. I have always resented that idea to an extent. Because it is clearly not true. We do not have to look any further than Italian supercars, which are beautiful and fast. With enough time, love for the craft and dedication, you can have a product that is fast, well made and beautiful. It is not easy, but it is possible.

That is a large part of why I made this.

A launcher that looks beautiful but takes four seconds to open is not a beautiful launcher. Its slowness is part of the experience. And a launcher that starts instantly but looks like a settings dialog is not a great launcher either.

I wanted both.

Because to me, a product isn't truly beautiful unless it feels good to use, and it isn't truly fast if speed is the only thing it has going for it.

The goal was to make zenkai look good the first time you run it, before you have configured a single thing. No config file, no wiki page, no spending half an hour tweaking colors just to make it presentable. Install it, launch it, and it should already look like something somebody cared about.

But good defaults should not get in the way of making it yours. Changing the entire look of zenkai is just a CLI flag away, so it can fit into whatever setup you already have without turning customization into a project of its own.

launchpad, which is the one I spent the most time on and the least sure about

The other half of that goal is fitting in. Most people who care enough to rice their desktop have already picked a colour scheme, usually from the list everybody uses, and they do not want to pick a second one for their launcher. So all of the popular ones are in there, gruvbox, dracula, ayu, catppuccin in all four flavours, tokyo night in its four variants, nord, rose pine, kanagawa, everforest, noctis, solarized, monokai, one dark, github, and plenty more.

ayu-dark

dracula

gruvbox

There is a screenshot of every single one of them in the screenshots directory on GitHub, if you want to pick before you install rather than after.

That works because Qt styles a widget set through QSS, which is Qt’s stylesheet format, and a theme in zenkai is a data file rather than code. That is the whole reason there are 65 of them and the reason adding another one is not work. You are not writing a new screen, you are filling in colours.

retro, which is amber on black and is not a colour scheme anybody ships

I also did some creative ones that are not really anybody’s scheme. And the one I am genuinely proud of is the native Windows theme, because it reads your accent colour and themes itself around it, so on a machine where you have already told Windows what colour you like, zenkai just quietly agrees with you.

Then there are the two high-contrast themes, and those exist for one reason only, which is accessibility. Pure black on pure white, bold everywhere, no greys at all, and every state inverts completely instead of tinting.

high-contrast

Most schemes spend their greys on the dimmed text and the inactive borders, and greys are exactly what disappears on a bad screen or with low vision. Not being able to see which row is selected every single time you open a launcher is a real problem, so these two throw the greys out entirely. There is a dark and a light version and nothing left to tune.

Zenkai Is Yours Too

A theme gets you most of the way there, and then there is the stuff a theme cannot do.

Some of that is just flags. --menu is the one I use most, because it lets me put my own entries into the launcher without writing anything. --menu=gh|GitHub|github-icon and suddenly a search for gh opens a browser tab instead of starting an application. There are flags for the icon size, the window size, which monitor it opens on, whether the animations run at all. It is a launcher that assumes you want to bend it, which is not an assumption most of them make.

The rest is Lua, through ziglua, so themes and actions can be extended without rebuilding. That was supposed to be the small feature. plugins.zig is now 26KB where I expected a fraction of that, which is what happened the one time I said it would be small.

The part that took the most work was the sandbox, because embedding a scripting language in a GUI application turns out to need three separate things and I only know the list because I got the first two wrong. Capabilities get removed rather than policed, so there is no permission list for a plugin author to misconfigure. And there is an instruction limit, because a plugin stuck in an accidental infinite loop hard hangs the whole window, since the Qt event loop is sitting on the other side of that call and never gets a chance to run again. Errors go to the log instead of stdout, attributed to the plugin that caused them.

That list deserves its own post, so I am not going to stretch it here.

What I Want It To Become

The honest version is that this started as a launcher and keeps turning into something else, and I am fine with that.

The biggest thing I want is more capabilities. Right now it launches applications and runs things, which is a launcher. What I actually want is closer to what Vicinae and Raycast do, which is a command palette with genuinely useful commands beyond starting processes. Clipboard history, quick calculations, scripts, window and workspace control, that whole category. I use a launcher every single day and the fastest thing on my keyboard right now is starting applications, which is a waste of a good global hotkey. And I do not mean that as a complaint, because the thing already keeps a scorecard of what I actually use it for, so at that point it might as well be funny about it.

I also want a Hyprland commander mode, which is a slightly more niche thing but I use Hyprland and I want zenkai to be able to drive it properly rather than being an application launcher I happen to also run on that machine.

And then there is the part that is less fun to admit, which is technical debt and performance. A few months in, this has left some genuinely ugly corners that I know about and have been choosing not to look at, in the way you do not open a file you know is going to cost you an afternoon when you are having a good day. Technical debt is a bad joint, you can get away with one and you can get away with a few if you are careful about which ones, but eventually the whole thing comes apart in your hands and you find out which ones mattered all along. I want to clean that up properly. And I want it faster still, because 140ms is a good number and there is no reason it should be the number I stop at.

Build Something

None of the parts I am actually proud of were the plan. The lazy icons came from realising I was paying for a hundred rows nobody would see, the deferred scan came from wanting the window up before anything heavy started, and the whole thing got fast because I was stubborn about a number in a way I never get to be at work.

So if you have been uninstalling launchers looking for one, or if you have looked at Zig and wondered whether it is any use for anything graphical, this is my answer to both. Go build the thing you kept looking for, even if the only reason it does not exist yet is that nobody bothered.

Going Deeper

Time for some more honesty, this post was originally A LOT longer, I had to trim it down to something more reasonable to not bore most of you. Striking a good balance between technical detail and readability is hard, and I am not sure I got it right. So I am going to write at least 3 more posts where I go into the details of how I got it to be fast, how I got it to be beautiful, and how I got it to be cross-platform. The first one will be about performance, because that is the part that took me the longest to understand and the part that I am most proud of.

What I have written here is the short version. There is a lot underneath it and I want to go through it properly, because the interesting parts are the ones that took me the longest to understand and I have mostly just said they work.

So that is what is coming. Getting the whole thing under 200ms, including the scan of every application on the machine, and what happens in the sub 50ms cases when there is nothing left to skip. How it actually beat the Windows Run utility, which is a native dialog with no Qt runtime to load, and why a Qt application in Zig winning that was never really in doubt once I understood where the time was going. How I got Windows application discovery working at all, given that Windows describes the same application in five different places and some applications only exist in one of them, and why the honest answer there involved 148 lines of C++ in an otherwise pure Zig codebase.

If you want the reasoning rather than the result, those are the ones worth reading.

Try It

Check it out at zenkai-launcher.netlify.app, the source is on GitHub.

Give it a go. If you like it, drop the launcher a star on github or just a hey wassup, I like your launcher on Twitter, I will genuinely appreciate it.

Thank you for your time and patience reading this article

Why Bun leaving Zig is Great for Zig

Dayvster 🌊 — Mon, 25 May 2026 21:12:47 +0000

The tech internet is reacting exactly how you would expect to the news that Bun has merged a near-total rewrite from Zig into Rust. Most of the Rust crowd is out in full force celebrating it as another big win for their side. They are already writing off Zig as some niche language that is not built for the future.

They are missing the point.

This is not cope. This is not some Zig fanboy rant. It is a realistic look at a very risky engineering decision with real consequences for the people who actually have to ship and maintain this thing.

The Gamble

Anthropic bought Bun in December 2025. The exact amount they paid is still unknown. Speculation ranges from a lowball one million dollars all the way up to around one hundred million. We do know Bun had raised roughly twenty six million before the acquisition. That is a serious amount of money for a JavaScript runtime, but it is basically nothing to a company valued at three hundred and eighty billion dollars.

Even if they paid the full one hundred million, it would be like you or me walking around with one thousand dollars in our bank account and buying a pack of gum or a cup of coffee. Not exactly a dangerous bet for Anthropic.

The online crowd is acting like this rewrite is already a guaranteed success just because they switched to Rust. In reality this is a high-stakes gamble, mostly for the Bun team. They are the ones whose reputation is on the line if things go wrong.

Four Possible Outcomes

Scenario A: It Actually Works

The translated Rust code ends up fast enough and mostly stable. Anthropic gets to show it off as proof that their AI can rewrite large systems code. Bun ends up with the same product they already had, just written in a different language.

Even in this best case there is a catch. Early checks on the Rust port showed over thirteen thousand unsafe blocks because the AI just carried over the old Zig pointer style. The Rust community might end up doing a bunch of unpaid cleanup work on the messy generated code. So even if it ships, it could still be a weird Frankenstein project under the hood.

Scenario B: Flaky and Unreliable

The runtime mostly runs but has weird regressions, random panics, and edge cases that tests did not catch. Anthropic will probably downplay it and call it progress. For the Bun team this would be painful. A lot of people picked Bun specifically because it promised incredible performance. If that trust breaks, many will quietly switch back to Node or Deno and never look back.

Scenario C: Total Disaster

The new codebase has serious bugs that break production apps for users. Upgrades become a nightmare. Anthropic takes a small hit to their image but keeps running their main business without much trouble. How ever bun as a product might no longer really exists after such an event. Once trust is gone in the JavaScript runtime space it is very hard to get it back. The project could slowly fade into irrelevance.

Scenario D: It Works But Becomes Maintenance Hell

This is the one a lot of people are not talking about. The code compiles, passes the tests, and mostly works in production. But the generated Rust is ugly, hard to read, and full of weird patterns that no human would write. Over time it becomes much more painful to maintain and extend than the old Zig version ever was.

New features take longer, bugs are harder to track down, and the original Bun team ends up spending most of their time fighting the codebase instead of improving the runtime. Users get slower progress and the project loses momentum even if nothing catastrophic happens. This is probably the most likely middle-ground outcome.

Outcome Breakdown

Scenario	Anthropic Result	Bun Team Result
Clean Success	Big Win	Break-even
Flaky and Unreliable	Small Win	Loss
Total Disaster	No Real Damage	Horrible Loss
Works But Maintenance Hell	Minor Win	Slow Pain / Stagnation

What Did Zig Actually Lose?

Pretty much nothing important.

They lost a corporate sponsor check and a team that never really fit the Zig way of doing things.

Zig is about taking it easy, moving carefully, and doing the work right. It is built for patient craftsmanship. The Bun team was running on a completely different mindset. They operated in full hype mode, rushing everything out to feed the JavaScript ecosystem’s demand for speed.

That constant rush led to a lot of breakage. Instead of owning it, they blamed Zig. They pointed at the pre-1.0 compiler and breaking changes as the reason their runtime kept feeling unstable. They even forked the language and tried forcing lifetimes and heavy AI patches into it, trying to turn Zig into something it was never meant to be.

Ditching that mismatch is probably a relief for the Zig project.

But the real gift is what comes next. Anthropic just paid for the cleanest before-and-after comparison the Zig community could ever ask for. We had Bun running on Zig for years. That was the before. Now we have the exact same codebase, same architecture, and same team running on a machine-translated Rust version. That is the after.

No more excuses. No more arguing about pre-1.0 volatility or breaking changes. All the variables are removed. The Zig community now gets to watch what happens in plain sight.

If Bun suddenly becomes rock solid and reliable, then maybe Zig really was holding it back. But if the flakiness, regressions, and instability follow it into Rust anyway, that will be very telling.

Zig didn’t lose its flagship project. It let a multi-billion-dollar company pay for the crash test.

In Defense of Manual Memory Management

Dayvster 🌊 — Mon, 25 May 2026 21:11:01 +0000

Why Manual Memory Management Still Matters ?

It is now easier than ever to write software without ever needing to learn about the heap or the stack. Languages like JavaScript, Python and even Go have built-in ways to manage your memory usage for you at runtime with acceptable performance hits for most modern consumer grade hardware. However consumer hardware is not the end all be all of computing. There are still many use cases where the performance benefits of manual memory management are worth the effort, such as in embedded systems, game development, and high-performance computing.

I'd even argue that it's a valuable skill to have and learn even if you don't need it for your day to day work. It can give you a deeper understanding of how computers work and how to optimize your code for performance.

When you understand how memory management works how your system works under the hood, you will also as a third order effect understand your own code and software better. Plus you can then use super cool and trendy languages like Zig, Odin and C3 which have manual memory management as a core feature.

The Usual Pitfalls

Here are some things that you should be aware of when doing manual memory management:

Dangling Pointers

A dangling pointer is a pointer that points to memory that has already been deallocated. Imagine lending your friend a book and making a note of it and when you go to ask for it back they tell you that they've already thrown it away, rude yes, but now you have a note that points to a book that no longer exists. Bad analogy aside a dangling pointer is a pointer that points to memory that has already been freed, and if you try to access it you will get undefined behavior, which can lead to crashes, data corruption, and security vulnerabilities.

Double Free

Continuing my bad analogy say that you've lent your friend a book and now you wish to throw it away, so first you have to get it back from your friend, who has rudely already thrown it away, even though you wanted to throw it away yourself. So you attempt to throw away a book that has already been thrown away. Wow I'm really bad at this whole analogy thing. Regardless, a double free is when you try to free memory that has already been freed, and this can lead to undefined behavior, which can lead to crashes, data corruption, and security vulnerabilities.

Use After Free

You know what I'm sticking to my bad analogy, so say that you've lent your friend a book and then you attempt to read it after your friend has already thrown it away, you will get a book that is no longer there and you will be confused and upset. This is what happens when you try to access memory that has already been freed, you will get undefined behavior, which can lead to... yes you've guessed it, crashes, data corruption, and security vulnerabilities.

Leaking Memory

Your friend lives in a small apartment and you lend them a book, then you lend them 10 more books and after that you just keep lending them books like the crazed book lender that you are without ever asking for them back. Eventually your friend will have a huge pile of books that they can't manage(that'll show em) and they will have no space left in their apartment. This is what happens when you allocate memory but never free it, you will eventually run out of memory and your application will crash. This is called a memory leak, and it can be a serious problem if not managed properly.

Buffer Overflows

Your friend is a bit OCD they reserved a singular bookshelf for the books you lend them, it only has space for about 10 books because your very OCD friend likes the number 10, so you lend them 10 books one week and the next week you lend them 1 more book. Your friend has a meltdown because they have 11 books and can't fit them on their shelf that can only ever hold 10 books. Yes I am sticking to my bad analogy. A buffer overflow is essentially when you try to write more data to a buffer than it can hold. Guess what this can lead to? Yes you guessed it, crashes, data corruption, and security vulnerabilities.

Memory Fragmentation

Your very OCD friend built a bigger shelf and has a new strategy of how to place books on that shelf, they wanna sort them alphabetically or by color or something I don't know it's an OCD thing. So you keep lending them book chaotically which leads your friend to have a bunch of empty space between the books on the shelf, the shelf itself is bigger yes, but the empty space between the books is wasted space that can't be used for anything else. This is what happens when you have a lot of small allocations and deallocations, it can lead to memory fragmentation, which can lead to inefficient use of memory and eventually running out of memory.

Incorrect Ownership

Ok I got no idea how to work my bad analogy into this one, you and your ... roommates ? all try to modify the same book on the shelf at the same time, this opens a rift in the space time continuum because somehow you've now produced a quantum book that exists in multiple states at the same time, and you have no idea which state is the correct one. Wow that went off the rails real quick. Incorrect ownership is basically when you have multiple pointers to the same memory and each of them tries modifying it. This can lead to race conditions and data corruption, and it can be very difficult to debug.

As you can see doing manual memory management is a lot more involved than just using a garbage collected language, but it can also be a lot more rewarding and fun. You get to have more control over your application's memory usage and you can really optimize your software for performance and for known hardware. However, you also have to be very careful and pay attention to the details, because if you make a mistake it can lead to some very bad consequences.

How To Avoid These Pitfalls

Just use a garbage collected language, problem solved. End of article. Just kidding, if you want to do manual memory management there are some things you can do to avoid these pitfalls, you've already solved the biggest problem by now which is understanding the pitfalls (I hope). But just understanding the problem is only half the journey the solution is the other half. So let's think about some solutions to these problems.

The Mental Model

The first thing you need to do is to have a mental model of how memory management works. Let's start with 2 terms which immediately describe what they do, the stack and the heap.

Stack

For a stack we always default to a stack of plates when describing it because it's the easiest way to visualize it, you can only add or remove plates from the top of the stack because we really do not wanna break any plates. So the stack is a region of memory that is used for storing local variables and function call information. It is organized in a last-in-first-out (LIFO) manner, which means that the most recently added item is the first one to be removed. The stack is typically much faster than the heap because it has a fixed size and does not require dynamic memory allocation.

Heap

For the heap imagine a big disorganized pile of clothes, you can very quickly throw clothes onto the pile and you can also quickly grab clothes from the pile, but you have no idea where anything is and it can get really messy really fast. The heap is a region of memory that is used for dynamic memory allocation. It is organized in a more flexible manner than the stack, which means that you can allocate and deallocate memory in any order. The heap is typically slower than the stack because it requires dynamic memory allocation and deallocation.

I could easily write full articles on just the stack and just the heap alone but for the sake of keeping your attention span I think this is a good enough mental model to get you started.

Tools and Tricks

Use the tools available to you. We have debuggers and sanitizers, logging and profiling tools, and even static analysis tools that can help you catch these issues before they become a problem. Use them, they are there for a reason and they can save you a lot of time and headaches.

Debuggers: A debugger is a tool that allows you to step through your code line by line and inspect the state of your program at any point in time. This can be incredibly helpful for finding and fixing memory management issues, as you can see exactly where things are going wrong.
Sanitizers: Sanitizers are tools that can help you detect memory management issues at runtime. For example, AddressSanitizer can help you detect buffer overflows and use-after-free errors, while LeakSanitizer can help you detect memory leaks.
Logging and Profiling Tools: Logging can help you track the flow of your program and see where memory is being allocated and deallocated. Profiling tools can help you identify performance bottlenecks in your code, which can be caused by inefficient memory management.
Static Analysis Tools: Static analysis tools can analyze your code without running it and can help you find potential memory management issues before they become a problem. For example, tools like Clang's static analyzer can help you find potential memory leaks and other issues in your code.
Code Reviews: Code reviews can be a great way to catch memory management issues before they make it into production. Having another set of eyes on your code can help you spot potential issues that you might have missed, ask a friend to review your code if it's a hobby or solo project if you have to, just maybe not the same friend that you lend books to in the previous analogies, they might be a bit overwhelmed at this point.

Best Practices and Habits

Tools are great and all but at the core of manual memory management is you, the developer. You need to have a good set of habits and practices that can help you avoid these pitfalls in the first place. By delving into the world of manual memory management you take responsibility for your own code and you have to be disciplined about how you manage your memory. Here are some best practices and habits that can help you avoid these pitfalls:

Always Free What You Allocate: This is the most basic rule of manual memory management, if you allocate memory you need to make sure that you free it when you're done with it. This can help you avoid memory leaks and ensure that your application does not run out of memory.
Use Smart Pointers: If you're using a language that supports smart pointers, such as C++, use the tools they give you, smart pointers are easy to learn and they can help you avoid a ton of pitfalls listed above like dangling pointers, double free, use after free, and even incorrect ownership. They are a great way to manage memory safely and efficiently.
Favor scope-based cleanup: If your language supports it, use scope-based cleanup mechanisms. In C++, this is RAII (Resource Acquisition Is Initialization), where resources are automatically released when they go out of scope. In Zig, you can use defer to schedule cleanup code that runs when a block ends. These tools help prevent memory leaks and make sure your application doesn’t run out of memory.
Test small and often: When you're doing manual memory management, it's important to test your code frequently and in small increments. This can help you catch issues early on before they become bigger problems. Write unit tests that specifically test the memory management aspects of your code, and run them regularly to ensure that everything is working as expected.
Respect your future self, document your damn code: You will forget about the details of your code in the future, especially when it comes to manual memory management. Make sure to document your code well, especially the parts that deal with memory management. This can help you understand your code better in the future and can help you avoid making mistakes when you come back to it later on.

How Different Languages Tackle Manual Memory Management

Ok we're done with bad analogies for now, so let's discuss how different languages that do not come with a garbage collector handle manual memory management, and how they help you avoid the pitfalls mentioned above.

C

C is a fine classic, it's timeless and beautiful in its simplicity. I appreciate just how minimal it is and how much you can do with just raw C and the standard library. Famously C has malloc and free for manual memory management, and it is up to the developer to make sure that they are used correctly. C does not have any built-in tools to help you avoid the pitfalls of manual memory management, so you need to be very careful when using it. However, there are many third-party libraries and tools that can help you manage memory in C, such as Valgrind for detecting memory leaks and AddressSanitizer for detecting buffer overflows and use-after-free errors.

But recently we've gotten some new tools and helpers in the C ecosystem such as Fil-C.

Fil-C

Fil-C is a modified toolchain that adds a ton of memory safety to C and C++ at a very minimal cost and no need for expensive rewrites to other languages or paradigms which may lead you to throw away decades of battle tested code and bugfixes.

What Fil-C delivers is:

Modified Compiler: Fil-C uses a modified compiler based on LLVM/Clang that instruments your code during compilation. It rewrites pointer operations and inserts safety checks so that invalid memory accesses such as out of bounds reads or writes are detected at runtime.
Custom Runtime: Fil-C links programs against its own runtime which is responsible for enforcing these safety guarantees. It tracks memory objects, validates pointer accesses, and aborts execution if the program attempts an unsafe operation.
Modified Standard Library: The C standard library used with Fil-C is adapted to operate within the same safety model. This ensures that safety guarantees apply consistently across both your code and the libraries it depends on.
A Memory Safe ABI: Fil-C programs run with a modified application binary interface designed to support its safety checks and metadata tracking. This ABI allows the runtime to reliably enforce memory safety across the entire program.

Together, these components allow Fil-C to keep the simplicity and ecosystem of C, while adding a layer of protection against many of the most common and dangerous memory errors.

But the magic happens when you compile your existing C or C++ code with the Fil-C compile, it will automatically rewrite your code to add safety checks, insert runtime checks and link against the Fil-C runtime, all without you having to change a single line of your code. This means that you can take your existing C or C++ codebase and compile it with Fil-C to get memory safety guarantees without having to rewrite your code or change your programming paradigm.

Essentially something like

int x = arr[i];

Will compile to something sorta like:

check_pointer_bounds(arr, i);
load_value(arr + i);

C++

Ah yes the one everyone loves to hate but also the one that has had one of the biggest impact on the software industry. I know C++ gets a bad rep, in fact I even wrote a whole article in defense of C++ give it a read if you have some time. But back to the main point, C++ has evolved a lot since its inception and it has added a lot of features to help with manual memory management in a safe and controlled way, such as smart pointers which are basically wrappers around raw pointers that automatically manage the memory they point to.

Also modern C++ strongly encourages the use of containers instead of manual memory allocation, usually if you use the following: std::vector, std::string, std::map, std::unordered_map and so on, you will be using manual memory management under the hood but you won't have to worry about it because the containers will take care of it for you.

Trouble arises if you use something like:

int* arr = new int[10];

This is a raw pointer and you will have to manually manage the memory for it. The same can be achieved with

std::vector<int> arr(10);

This will give you a vector of 10 integers and you won't have to worry about memory management

Zig

My favorite of the bunch, Zig is a modern programming language that has manual memory management as a core feature. It has a unique approach to memory management that is designed to be safe and efficient, while still giving developers full control over their memory usage. You can accomplish this by understanding zig allocators and using them correctly in your code. Zig also has the defer keyword which allows you to schedule cleanup code that runs when a block ends, this can help you avoid memory leaks and ensure that your application does not run out of memory.

Basically Zig gives you the tools you need to manage your memory safely and efficiently with minimal effort on your end and all this with basically no overhead or significant performance hits, it's a win-win situation.

Plus zig can interop with C and even be used as a C or C++ compiler.

Odin

I've covered how Odin manages memory in is odin just a more boring C? the title is a bit clickbaity, I'm sorry about that, I mean it in a good way, I like a language that is simple and straightforward and gets out of my way and lets me be productive. Odin is precisely that and I love it. I really would recommend reading through my article on Odin because it has a very cool and unique approach to manual memory management that is worth learning about.

What makes Odin interesting when it comes to memory management is that it does not try to hide memory from you. Instead it makes it explicit and flexible through allocators. In Odin you can pass allocators around just like normal values and decide exactly how memory should be handled in a given part of your program. Many APIs also default to using context.allocator, which gives you a convenient default while still letting you override it when needed.

This means you can easily switch strategies depending on the problem. Maybe you want an arena allocator for short lived data, or a custom allocator for a performance sensitive subsystem. Odin makes that kind of thing straightforward.

In practice this leads to code that is very predictable. You know where allocations happen, you know who owns them, and you can change the allocation strategy without rewriting half your program. It fits nicely with Odin’s general philosophy of simplicity and control.

C3

I have not had the time to properly dive into C3 yet. I tinkered with it a bit and I like the direction they are taking.

From what I have seen so far, C3 leans heavily on scope based allocation and deterministic cleanup. The idea is that a lot of memory you allocate only needs to live for the duration of a function or a block. Instead of manually tracking every allocation and freeing it later, the language and its libraries make it easy to tie allocations to a scope and clean them up when that scope ends.

C3 also provides helpers like mem::new_array and mem::alloc_array in the standard library so you are not constantly dealing with raw allocation primitives. The project also promotes the use of temporary or arena style allocators for short lived data.

What I like about this approach is that it tackles one of the biggest sources of memory bugs which is lifetime confusion. If allocations clearly belong to a scope, a lot of mistakes simply disappear.

I still need to spend more time with C3 before forming a strong opinion, but from what I have seen so far it looks like another interesting attempt at making manual memory management practical instead of painful.

The Rust Detour

I'll be honest with you, I don't consider Rust to be a manual memory management language. It's a language that has a unique approach to memory management yes but at no point does it require you to manually allocate and deallocate memory, it has a built in ownership system that takes care of all of that for you. Rust is basically a set of compiler rules which basically just shifts the responsibility of memory management away from the developer, if that sounds familiar it's because that's precisely what garbage collected languages do. They assume you will mess up and they take care of it for you, Rust just does that at compile time instead of runtime.

Is that a good approach? Honestly no. I think it's a horrible approach that adds more problems than it solves and in the end it does not even guarantee memory full safety, that's how you get the famous quotes like memory leaks are considered memory safe in Rust. So far Rust has failed to impress in production as well such as when Cloudflare went down because of a memory issue in their Rust code, a problem Rust was specifically designed to prevent.

As you can tell I'm not a fan of Rust and I don't think it's a good language at all. It came in hot with wild promises and failed to deliver on any of them so far, but that's a topic for another article.

When Should you Reach for Manual Memory Management?

Manual memory management is really powerful and if you understand it well you can write incredibly efficient and performant code, but it also comes with a lot of responsibility and potential for mistakes. So when should you reach for manual memory management?

Performance Critical Code

In high performance systems, even small inefficiencies can add up. Games, trading systems, real time audio processing, and high frequency networking software often benefit from predictable memory usage and deterministic cleanup.

Garbage collectors can introduce pauses or unpredictable allocation patterns. Manual memory management allows developers to control exactly when allocations happen and when memory is released.

Embedded Systems

Embedded devices often run with extremely limited memory and CPU resources. A garbage collector may simply be too expensive or too unpredictable in these environments.

Manual memory management lets developers carefully control how memory is used and ensures that the system never exceeds its constraints.

Systems Programming

Operating systems, drivers, compilers, and networking stacks all tend to require direct control over memory. In these areas you often need to manage memory layouts explicitly, work with hardware, or operate in environments where a runtime simply does not exist.

Large Existing Codebases

Sometimes the reason is simple. There are decades of battle tested C and C++ code in the world. Rewriting those systems into a different paradigm or language is often unrealistic or would lead to throwing away decades worth of battle tested code and bug fixes.

In those cases it makes more sense to improve tooling, add safety layers, or adopt better practices rather than start over from scratch.

And that is really the key point. Manual memory management is not something you reach for just because you can. It is something you use when you need control, predictability, and performance that higher level runtimes cannot always provide.

Understanding it also changes how you think about software in general. Once you know what is actually happening under the hood when memory is allocated, freed, or reused, many parts of programming start to make a lot more sense.

Conclusion

Manual memory management has a reputation for being dangerous and outdated, but that reputation mostly comes from misunderstanding and misuse.

Yes, the pitfalls are real. But so are the performance benefits and the deeper understanding of how software works that comes with mastering it.

The reality is that manual memory management is still everywhere. Operating systems, game engines, databases, embedded systems, networking stacks and high performance software all rely on it every day. Entire industries run on systems that manage memory manually and have done so successfully for decades.

What has changed is the ecosystem around it. We now have better debugging tools, sanitizers, static analyzers and improved language features that make writing safe manual memory code far more approachable than it used to be. Modern C++, Zig, Odin and C3 are all exploring different ways to give developers control without unnecessary pain.

At the end of the day, manual memory management is just another tool in the toolbox. Not every project needs it, and for many applications a garbage collected language is perfectly fine. But when performance, determinism or low level control matter, understanding manual memory management becomes incredibly valuable.

And honestly, once you understand it, it stops being scary. It just becomes another part of writing good software.

Thank you for your time, this was a long one and I sincerely hope you enjoyed it.

AI’s Trap: Settling for Boilerplate Over Elegant Code

Dayvster 🌊 — Mon, 27 Oct 2025 11:04:09 +0000

We are all familiar with Picasso's "The Bull" series, in which he progressively simplifies the image of a bull down to its most basic, yet still recognizable form. Steve Jobs was famously inspired by this concept, leading him to advocate for simplicity and elegance in design and technology above countless features and excessive complexity. Distill a concept even as complex as software or UX down to its essence, and what you are left with is something beautiful and elegant that fulfills its purpose with minimal fuss.

So Why Do We Accept Ugly Code Then?

I've noticed a worrying trend in programming that, as tools around a programming language improve and automate more of our work, we increase our tolerance for boilerplate, repetitive, and frankly, ugly code. We accept it and we tell ourselves it's ok, the linter will fix it, the formatter will fix it, the compiler will optimize it, in the end it's all ones and zeroes anyway, right, why would any of this matter?

Since AI has entered the equation, tolerance for boilerplate and excuses for ugly code has only increased. We tell ourselves that as long as the AI can generate the code for us, it doesn't matter if it's elegant or not. After all, we didn't write it, the AI did. So why should we care about the quality of the code? After all, we relinquished ownership of the code the moment we asked the AI to generate it for us.

Now, you may not be someone who uses AI to generate code, and kudos to you, welcome to the club, however, even as someone who relatively early noticed that AI does not produce something that I could sign off on as my own work proudly and with confidence. I have engaged in the practice of using AI to generate some more tedious tasks for myself, such as just taking a JSON response from an API and asking Copilot, ChatGPT, or Grok to generate a type definition in the language I am currently working with.

I work on many personal and professional projects, and I encounter different types of people and teams, some embrace AI, others shun it. However I have noticed that in teams or projects where AI is embraced or even encouraged or mandated as part of the development process, tend to produce a lot of boilerplate and a lot of very ugly inelegant code that few wish to take real ownership of, because it is not their creation they handed ownership of it to the AI and therefore abandoned the developer - code relationship that is so essential to producing quality software.

Developers Should Love Their Code

I harp on this a lot, development is a unique one of a kind blend of engineering and creative expression, those two aspects of our craft should not be at odds with each other, but should rather complement each other.

When you write code, you should love it, you should be proud of it, you should want to show it off to others who can understand it and appreciate it, in essence, your way of expressing your way of thinking and how you tackle problems.

I've briefly touched upon the fact that handing off ownership of your code to AI means abandoning that relationship between you, the developer, and your code. I want to expand on that a bit more. If you don't care about the code you write, if you don't love what you are doing or the creative process to solve a specific problem, you will forever lack understanding of that specific problem that you are solving. It will get solved for you by the AI, and you will rob yourself of the opportunity to learn and understand that problem on a deeper level.

This is something that has kicked me in the ass a fair few times in the past, I'd get a problem to solve, think oh this is easy, draft up an initial solution solve the problem at a very superficial level and then in the coming weeks get 10 QA tickets filed against that problem because there is more to the problem than meets the eye and there are often things that you miss or do not even consider during your first implementation.

AI will do exactly the same thing every single time. The difference, though, is that every time I was given a problem to solve, it resulted in fewer and fewer QA tickets because I understood and learnt from my past experiences and mistakes and knew how to approach problem-solving more effectively.

AI will not do any of that, it will always solve the problem given to it at face value without any deeper understanding or context. It will not learn from past mistakes, grow, or adapt its mindset to shift its approach based on new information or insights. It will always solve the problem, and worst of all, it will never learn to understand the problem so well that it can simplify the solution down to its essence and produce something elegant.

There is a certain beauty to solving a problem and all of its potential side effects in a very minimal and easily readable way. That is an ideal that I strive for in my own work, and I encourage you to do the same. Love your code, be proud of it, and strive for elegance over boilerplate.

The Cost of Boilerplate

Boilerplate code is not just an eyesore, it comes with real costs. It increases the cognitive load on developers, makes the project less enjoyable to work on, and increases the time to onboard new team members. And increases the time to fix or resolve issues, which directly impacts the experience of the end user of your product.

As a third-order effect, it also increases the soft requirement for more tooling and more AI assistance to manage and maintain your codebase, which is a dangerous spiral best avoided altogether.
A question I've been asking myself is how much of this is by happenstance and how much of this is by design. I don't want to get all conspiracy theorist on you, but it does make me wonder if there are vested interests in making us accept boilerplate and ugly code as the norm, because it increases the demand for AI tools and services that can help us manage and maintain our codebases. I'm not confident enough to attach any weight to this thought, but it's something worth pondering.

Aesthetic Responsibility

It's very easy for us as developers to simply dismiss aesthetics as something superficial and unimportant in the grand scheme of things. After all, we are not building art, we are building software that solves problems and delivers value to users. However, I would argue that aesthetics play a crucial role in the quality and maintainability of our code.

When we write code that is elegant and beautiful, we are not just making it easier for ourselves to read and understand, we are also making it easier for others to read and understand. We are creating a shared language and a shared understanding of the problem we are solving and the solution we are implementing. When we write ugly and boilerplate code, we are creating barriers and obstacles for ourselves and others. We are making it harder to read and understand, we are making it harder to maintain and evolve, and we are making it harder to collaborate and share knowledge. We're increasing the friction instead of reducing it.

It always feels nice as a human to look at something beautiful, whether it's a piece of art, a well-designed product, a sports car, a building with stunning architecture, and so on and so forth. But when it comes to code, we often dismiss aesthetics as unimportant, after all, it's a means to an end, right? I would argue that as developers, we have an aesthetic responsibility to ourselves and to others to write code that is elegant and beautiful, not just for the sake of aesthetics, but for the sake of quality and maintainability.

But it is very easy lately to just let the tools we have been given and AI do the heavy lifting for us, and in doing so, we risk losing sight of our aesthetic responsibility as developers.

How Does AI Increase the Tolerance for Boilerplate?

You know the drill: you are working away on a piece of a project, and you're on a tight deadline with a backlog full of features to implement and bugs to fix. You think to yourself, "I just need to get this done quickly, I can refactor it later(a mindset I generally encourage)." So you ask the AI to generate the code for you, and it spits out a solution that does not work, so you refine your prompt and try again, and again, and again until you get something that works. Now you have a working solution, great! One quick glance at your git status, HOLY SH.. WHY ARE THERE 32 FILES CHANGED? AND WHY ARE MOST OF THEM NEW FILES?

Ok..OK, you have a working solution. It's best to open up a PR and let the Copilot PR bot handle the code review, and maybe a couple of co-workers will spot some things and suggest improvements. Once you have more time on your hands, you will absolutely go back and refactor this mess down to something elegant and beautiful. You just need to get this next task done first, oh, and it's on a tight deadline as well...

Before you know it, you have a codebase full of boilerplate and code that could easily be done in half as many lines or less, you will never go back and refactor it because there is always something more urgent to do, and the cycle continues.

Maintenance? Not a problem, we can just use AI to generate documentation for us or explain code blocks for us. Testing? AI can generate tests for us, no need to think about edge cases or test coverage. Performance? AI can optimize our code for us, no need to understand the underlying algorithms or data structures.

It creeps up on you slowly, but surely. AI stands as an excuse to not care about the quality of your code, but only the quality or functionality of your outcome. There's a lot to be said and discussed about this topic.

You might be rightfully asking yourself, does it even matter if the code is ugly and I feel no pride in it, as long as the end user gets the functionality they need?

"Good Enough" Is Not Good Enough

I always liked the saying, "How you do anything is how you do everything." It has multiple different explanations and interpretations, but to me, it boils down to this: if you accept mediocrity in one aspect of your life, you will accept mediocrity in all aspects of your life. Or, how you do the little things is how you do the big things.

If you accept "good enough" code, you will eventually have a good enough product on your hands that might have to compete with products that were built with care and pride. Do you want to deliver good enough products, or do you want to deliver great products that you can be proud of?

Completely ignoring the market and financial viability of this approach, will you be happy with the work you do if mediocrity is the standard you hold yourself to? Or worse, if mediocrity is the modus operandi of your team or company?

If you truly believe that "good enough" is good enough, then by all means continue down that path. But I urge you to test that belief, challenge it, start a project that you may never finish or get paid for, but attempt to take a complex concept and distill it down to its essence in the most elegant way possible, do what Picasso did with his bull series, and see how far you can push yourself to create something beautiful out of something complex while still maintaining its core functionality and purpose.

Conclusion

AI is a powerful tool that can help us be more productive and efficient, but it should not be used as an excuse to accept boilerplate and ugly code. As developers, we should strive for elegance and simplicity in our code, and we should take pride in the work we do. We should love our code and our craft, and we should never settle for "good enough" when it comes to the quality of our work.

Write code you would sign your name under.

If you've enjoyed this article and made it this far, thank you sincerely for your time. I hope it was worth it and that it sparked some thoughts and reflections on your own approach to coding and craftsmanship, and I sincerely hope it did not feel wasted.

If you have any thoughts or feedback on this article, please feel free to reach out to me on Twitter. I'm always open to discussions and feedback, or just general chit chat about just about anything I find interesting.

Why Zig + Qt Feels Like Doing the Impossible Right

Dayvster 🌊 — Wed, 22 Oct 2025 19:34:37 +0000

Intro

It's no secret that I love Zig, and it's also no secret that my favorite GUI framework by far is Qt. So naturally, when I discovered that there were Zig bindings for Qt I had to give it a try and build something with it. What I decided to build was a fairly rudimentary shopping list application, nothing fancy just one of my standard things I like to build when exploring a new GUI framework of any kind. Because a shopping list app is simple enough to not get in the way of learning the framework but also complex enough to cover a lot of the basic concepts that you'll need to know when building a GUI application such as handling user input, displaying data, responding to different events, sorting and filtering the data and so on.

The Library

For this article and experiment I went with libqt6zig, there are other bindings libraries out there for Zig but they are QML based whereas libqt6zig is a direct binding to the Qt C++ API which I tend to prefer and it interested me a lot more because direct bindings are generally more performant and a lot harder to do correctly, so I wanted to see how well it was implemented and how well it worked in practice. The results were frankly surprisingly good and I was able to build a fully functional shopping list application with it in a relatively short amount of time, with minimal friction or trouble, I did manage to segfault a couple of times but that's to be expected and honestly half the fun, made me kinda nostalgic in fact. I've also spoken about the library with its author and maintainer rcalixte who is a super nice and helpful guy with an enthusiasm for tech and programming that is infectious and I can really relate to. So honestly if you've ever done any GUI programming before and you're interested in trying out Zig for GUI development I highly recommend you give libqt6zig a try, it's a solid library with a ton of potential.

The Experience

The very first touch point is the installation of the bindings to your Zig project, this is fairly easy and well documented here, after you install all your dependencies libraries, you can initialize your new zig project with zig init as you always would, then you simply need to add the libqt6zig bindings to your zig project, you can do this a number of ways but my personal favorite is to simply use zig fetch --save git+https://github.com/rcalixte/libqt6zig.

What does Zig fetch do?

The zig fetch command will add the specified dependency to your build.zig.zon with two fields, url and hash, the url field is the URL of the git repository and the hash field is a hash of the commit at the time you added the dependency, this ensures that your project will always use the same version of the dependency even if the repository is updated later on. You can also specify the hash in your zig fetch command by adding #<commit-hash> like so: zig fetch --save https://github.com/username/repository/archive/<commit> which will essentially lock your dependency to that specific commit. Note even if you omit the hash it will lock your dependency in build.zig.zon to the the latest commit at the time you added the dependency.

What it then does is fetch the contents of the repository and stores it in your zig cache directory .zig-cache, so that it does not need to refetch it every time you build your project nor does it need internet connectivity every time you build your project.

Using the Library

We're not quite done yet, after you've added the dependency to your project you need to actually link it in your build.zig file, this is fairly straightforward as well, you simply need to add the following lines to your build.zig file, so that zig build knows to link the libqt6zig library when building your project. Luckily rxcalixte has documented this process well in his readme in the Usage section. I recommend you check it out for the full details as it is subject to change and a link to the readme will always be best for the most up to date information.

OK Now let's Build Something

This is what we are building:

So as I've mentioned before I decided to build a simple shopping list application, nothing fancy just a basic CRUD application that allows you to add items to your shopping list, mark them as bought, upon which I want to apply some styles to it such as a strikethrough effect and a different color to indicate that the item has been bought and sort the item to the bottom of the list so that the unbought items are always at the top of the list. We also wanna be able to easily clean up the entire list with a single button click on "Clear All" or just clear all bought items with a click on "Clear Bought" which will only remove all the items that have been marked as bought.

Opening the Application Window

The first step to any GUI application is to first open the window, I won't make the obvious bad pun here, you're welcome for that by the way. To open a window with libqt6zig is fairly straightforward, you simply need to create a new widget and tell Qt to show it. That widget will serve as the main application window, and everything else.

const window = qwidget.New2();
defer qwidget.QDelete(window);
qwidget.SetWindowTitle(window, "Shopping List");
qwidget.SetMinimumSize2(window, 360, 480);

You might be confused by the use of New2 here instead of just New, this is because Qt has a lot of overloaded functions and Zig does not support function overloading, so the bindings library has to create multiple versions of the same function with different names to accommodate for that. In this case New2 is the version of New that takes no arguments, whereas New takes a parent widget as an argument.
After creating the window widget we set its title and minimum size, then we can show it by calling qwidget.Show(window);. Which I will do later after setting up the rest of the application, but if you are just playing around feel free to call it right after setting the title and size to see the window pop up.

Setting up the Layout

In Qt, layouts are what make widgets actually show up in a sensible way. to achieve what we have in the screenshot above we need to set up a vertical box layout or QVBoxLayout if you are familiar with Qt terminology. A vertical box layout is a layout that arranges widgets vertically.

const main_layout = qvboxlayout.New2();
qvboxlayout.SetSpacing(main_layout, 8);
qvboxlayout.SetContentsMargins(main_layout, 12, 12, 12, 12);

This makes a nice vertical layout with some breathing room for the elements it will contain.

Now let's make our first row which will contain the input field and the add button.

const input_row = qhboxlayout.New2();
qhboxlayout.SetSpacing(input_row, 6);
const item_input = qlineedit.New2();
qlineedit.SetPlaceholderText(item_input, "e.g. Milk, Eggs, Bread");
const add_btn = qpushbutton.New3("Add");
qpushbutton.SetFixedWidth(add_btn, 90);

What we have here is a horizontal box layout or QHBoxLayout that will contain our input field and add button. We set the spacing between the elements to 6 pixels for a bit of breathing room. Then we create a QLineEdit widget which is the input field where the user can type in the name of the item they want to add to their shopping list. We also set a placeholder text to give the user an idea of what to type in. Finally we create a QPushButton widget which is the add button that the user will click to add the item to their shopping list. We set its fixed width to 90 pixels so that it doesn't stretch too much.

That's the nice part about Qt+Zig every call here is explicit and tells you exactly what it does, no magic or hidden behavior, no global "current layout" no hidden parent assignments, just pure explicitness which I find a lot nicer to read.

Now we can attach our input row and add button to the horizontal layout and then the horizontal layout to the main vertical layout.

qhboxlayout.AddWidget(input_row, item_input);
qhboxlayout.AddWidget(input_row, add_btn);
// ...More code will go here
// Add the input_row to the main layout
// qvboxlayout.AddLayout(main_layout, input_row);

As you can see we are simply adding the widgets in the order we want them to appear in the layout, then taking that layout and adding it to the main layout. This should produce the top row of our application. But it won't do much so far, we still need to add the list view and the clear buttons.

Adding the List and Controls

Next up is the list where items will appear and the two control buttons at the very bottom with the labels "Clear All" and "Clear Bought".

const list_label = qlabel.New3("Items:");
qlabel.SetStyleSheet(list_label, "font-weight: 600; margin-top:6px; margin-bottom:2px;");
const list_widget = qlistwidget.New2();

Qt comes with a lot of useful widgets that you can use out of the box, in this case we are using a QLabel widget to display the "Items:" label above the list and a QListWidget to display the list of items. The QListWidget is a convenient widget that allows us to easily add, remove and manipulate items in the list. We also set a bit of styling on the label to make it look a bit nicer, if you are familiar with CSS this should look pretty straightforward to you.

Now for the bottom control row:

const controls_row = qhboxlayout.New2();
const clear_btn = qpushbutton.New3("Clear All");
qpushbutton.SetFixedWidth(clear_btn, 110);
const clear_bought_btn = qpushbutton.New3("Clear Bought");
qpushbutton.SetFixedWidth(clear_bought_btn, 120);

qhboxlayout.AddWidget(controls_row, clear_btn);
qhboxlayout.AddWidget(controls_row, clear_bought_btn);

Here we create another horizontal box layout for the control buttons, then we create two QPushButton widgets for the "Clear All" and "Clear Bought" buttons. We set their fixed widths to make them look a bit more uniform. Finally we add the buttons to the horizontal layout.

And just like that we can now bring it all together by adding everything to the main vertical layout in order.

qvboxlayout.AddLayout(main_layout, input_row); // input row goes here where it belongs
qvboxlayout.AddWidget(main_layout, list_label);
qvboxlayout.AddWidget(main_layout, list_widget);
qvboxlayout.AddLayout(main_layout, controls_row);

At this point our layout hierarchy looks like this:

Main Window
├── Input Row
│   ├── QLineEdit (item_input)
│   └── QPushButton ("Add")
├── QLabel ("Items:")
├── QListWidget (list_widget)
└── Controls Row
    ├── QPushButton ("Clear All")
    └── QPushButton ("Clear Bought")

Great! Now we got our layouts and widgets all set up we can get to my favorite part which is the logic and interactivity/functionality.

The Context System

One of the more clever parts of this app is how it maps each widget to its corresponding Zig state.
Because Qt signals are C-style callbacks with no built-in state, we use a global hash map to link each widget pointer to its appropriate state.

const AppCtxMap = std.AutoHashMap(?*anyopaque, *Context);
var ctx_map: AppCtxMap = undefined;

Each context holds references to the main widgets:

pub const Context = struct {
    window: ?*anyopaque,
    item_input: ?*anyopaque,
    list_widget: ?*anyopaque,
};

When we initialize the app, we register everything:

try ctx_map.put(window, ctx);
try ctx_map.put(item_input, ctx);
try ctx_map.put(add_btn, ctx);
try ctx_map.put(clear_btn, ctx);
try ctx_map.put(list_widget, ctx);
try ctx_map.put(clear_bought_btn, ctx);

That’s how any callback can later say:

fn get_ctx_for(self: ?*anyopaque) ?*Context {
    return ctx_map.get(self) orelse null;
}

The only problem and downside with this is that we are relying heavily on opaque pointers which are not type safe at all, so we have to be extra careful when working with them to avoid segfaults and other memory issues and this is precisely where I ran into some self inflicted issues and headaches with this application, completely my own fault for accepting a lack of type safety and memory safety for the sake of convenience, but it is what it is and it's not like I was building a production ready application here, I just wanted to be clever and explore Zig and Qt together, so I accepted the tradeoff. If you decide to build something more serious with this approach I highly recommend you find a way to make it more type safe and memory safe. This is just an example of me experimenting and exploring.

Hooking up the Logic

Now that we have the UI and context system ready, it’s time to connect everything together. This is where the application actually comes alive.
In Qt, widgets typically use a signal and slot mechanism, where signals (like button clicks) are connected to functions (slots) that respond to those events.
In libqt6zig, these signals are exposed as plain callback functions that you can assign in Zig, so you can handle events like button clicks in a straightforward way.

Handling the Add Button

When the user clicks Add, we want to:

Grab the text from the input field.
If it’s not empty, create a new list item.
Add it to the list widget.
Clear the input field.

fn on_add_clicked(self: ?*anyopaque) callconv(.C) void {
    const ctx = get_ctx_for(self) orelse return;
    const item_text = qlineedit.Text(ctx.item_input);
    if (item_text.len == 0) return;

    const list_item = qlistwidgetitem.New3(item_text);
    qlistwidget.AddItem(ctx.list_widget, list_item);
    qlineedit.Clear(ctx.item_input);
}

We connect this function to the Add button’s clicked signal:

qpushbutton.OnClicked(add_btn, on_add_clicked);

Handling the Clear Buttons

Next, we want to make the "Clear All" and "Clear Bought" buttons actually do something. The logic is simple:

Clear All: Remove all items from the list.
Clear Bought: Remove only items that have been marked as bought (we’ll handle this later by checking a property or style on each item).

fn on_clear_all(self: ?*anyopaque) callconv(.c) void {
    if (get_ctx_for(self)) |ctx| {
        qlistwidget.Clear(ctx.list_widget);
        return;
    }
}

fn on_clear_bought(self: ?*anyopaque) callconv(.c) void {
    if (get_ctx_for(self)) |ctx| {
        const count = qlistwidget.Count(ctx.list_widget);
        // iterate backwards so removing items doesn't shift unprocessed indices
        var i: c_int = count - 1;
        while (i >= 0) : (i -= 1) {
            const itm = qlistwidget.Item(ctx.list_widget, i);
            if (itm == null) continue;
            const state = qlistwidgetitem.CheckState(itm);
            if (state != 0) {
                // remove and delete the item
                const taken = qlistwidget.TakeItem(ctx.list_widget, i);
                // taken is removed from the widget; drop the pointer (Qt will clean up)
                _ = taken;
            }
        }
    }
}

As you can see in on_clear_all the logic is pretty straightforward, we simply call qlistwidget.Clear and give it a reference to our list widget, then Qt will handle the rest for us.

Now the more clever part comes in on_clear_bought, here we iterate through all the items in the list widget and check their state, however we know that we will sort bought items to the bottom of the list when the user ticks them as "done" or in this case "bought", so we can optimize this a bit by iterating backwards through the list and stopping as soon as we find an unbought item, because all bought items will be at the bottom of the list. This way we avoid unnecessary iterations and checks.

All there's left to do is to actually hook these two up to their respective buttons:

qpushbutton.OnClicked(clear_btn, on_clear_all);
qpushbutton.OnClicked(clear_bought_btn, on_clear_bought);

Marking Items as Bought

Finally, we need to handle changes to the items themselves. In our shopping list, items can be marked as bought by checking a checkbox next to them. In Qt, this is done via the CheckState property of a QListWidgetItem. Whenever the user checks or unchecks an item, we want to:

Apply a strikethrough effect to indicate that the item is bought.
Move the bought item to the bottom of the list to keep unbought items at the top.


fn on_item_changed(self: ?*anyopaque, item: ?*anyopaque) callconv(.c) void {
    if (get_ctx_for(self)) |ctx| {
        if (item == null) return;

        const state = qlistwidgetitem.CheckState(item);
        const is_checked = (state != 0);

        const font = qlistwidgetitem.Font(item);
        if (font) |f| {
            qfont.SetStrikeOut(f, is_checked);
            qlistwidgetitem.SetFont(item, f);
        }

        const row = qlistwidget.Row(ctx.list_widget, item);
        if (row < 0) return;

        const taken = qlistwidget.TakeItem(ctx.list_widget, row);
        if (taken == null) return;

        if (is_checked) {
            qlistwidget.AddItem2(ctx.list_widget, taken);
        } else {
            qlistwidget.InsertItem(ctx.list_widget, 0, taken);
        }
    }
}

Notice how we use TakeItem to temporarily remove the item from the list, then re-insert it in the appropriate position. This is a common trick in Qt when you want to reorder items dynamically.

Then we connect this callback to the list widget:

qlistwidget.OnItemChanged(list_widget, on_item_changed);

This ensures that every time an item's checkbox is toggled, the visual state updates and the item is moved accordingly.

Handling the Return Key

For convenience, we also allow the user to add items by pressing Enter in the input field. This is done using the OnReturnPressed signal of QLineEdit:

fn on_return_pressed(self: ?*anyopaque) callconv(.c) void {
    if (get_ctx_for(self)) |ctx| {
        const text = qlineedit.Text(ctx.item_input, allocator);
        if (text.len != 0) {
            add_item(ctx, text) catch return;
        }
        allocator.free(text);
    }
}

qlineedit.OnReturnPressed(item_input, on_return_pressed);

This function simply grabs the text from the input, adds the item if it’s non-empty, and clears the input field.

Adding Items Helper

Both the Add button and the Enter key use the same helper function to actually create and insert the list item:

fn add_item(ctx: *Context, text: []const u8) !void {
    const item = qlistwidgetitem.New7(text, ctx.list_widget);
    const flags = qlistwidgetitem.Flags(item);
    qlistwidgetitem.SetFlags(item, flags | qnamespace_enums.ItemFlag.ItemIsUserCheckable);
    qlistwidgetitem.SetCheckState(item, qnamespace_enums.CheckState.Unchecked);

    qlineedit.Clear(ctx.item_input);
}

This makes it easy to maintain consistent behavior across multiple input methods. Notice the 0x20 flag, this is Qt::ItemIsUserCheckable, which allows the checkbox to appear next to the item.

Result

At this point, all the interactive logic is wired up. Users can:

Type an item and press Enter or click Add to add it.
Check/uncheck items to mark them bought/unbought with a strikethrough effect.
Clear all items or only bought items using the respective buttons.
Automatically reorder items so unbought items remain at the top.

The result is a fully functional, minimal shopping list application built entirely in Zig using direct Qt bindings.

With the functionality in place, the next step is to make the application actually look nice. Qt widgets come with default styles that are functional but not particularly attractive. Fortunately, Qt supports CSS-like styling through SetStyleSheet, and libqt6zig exposes this feature directly.

Here’s the style sheet I used for the app:

const STYLE = 
  "QWidget { background: #121212; color: #e6e6e6; font-family: 'Sans'; }"
  "QListWidget { background: #1e1e1e; color: #e6e6e6; border: 1px solid #2a2a2a; }"
  "QListWidget::item { padding: 6px 4px; }"
  "QListWidget::item:selected { background: #2a2a2a; color: #ffffff; }"
  "QLineEdit { background: #222222; color: #e6e6e6; border: 1px solid #2a2a2a; padding: 6px; border-radius: 4px; }"
  "QLineEdit::placeholder { color: #9a9a9a; }"
  "QPushButton { background: #2a2a2a; color: #e6e6e6; border: 1px solid #333; padding: 4px 8px; border-radius: 4px; }"
  "QPushButton:hover { background: #313131; }"
  "QPushButton:pressed { background: #3a3a3a; }"
  "QLabel { color: #e6e6e6; font-weight: 600; }"
;

You can apply this style sheet to the main window like so:

qwidget.SetStyleSheet(window, STYLE);

Or alternatively, you can make a new file named style.qss and load it at runtime:

const qss_path = "src/shoppinglist/style.qss";
const qss_file = std.fs.cwd().openFile(qss_path, .{}) catch null;
if (qss_file) |f| {
    defer f.close();
    const data = try f.readToEndAlloc(allocator, 4096);
    qwidget.SetStyleSheet(window, data);
    allocator.free(data);
} else {
    qwidget.SetStyleSheet(window, STYLE);
}

This way you can easily tweak the styles without recompiling the app each time, additionally you can store this file anywhere on your system and allow users to customize the look of the app by providing their own style sheets if you want to get fancy.

Running the Application

Now we just need to show the window and start the event loop:

qwidget.Show(window);
_ = qapplication.Exec();

And there we have it, a simple yet fully functional shopping list application, built entirely with Zig and Qt using direct bindings, with not a hint of QML in sight. Sure, I opted to rely heavily on opaque pointers, trading off some type safety for convenience and rapid development, and I fully accept that tradeoff. For a more serious project, I would strongly recommend finding a way to make the code safer and more type-aware. Yet, despite these compromises, I was able to produce a complete, cross-platform GUI application in surprisingly little time and with minimal code. I honestly didn’t think it would be this straightforward. This is a testament both to the power of Zig as a systems programming language and to the excellent work of rcalixte in creating the libqt6zig bindings.

This wasn’t the only experiment I tried with libqt6zig. I also built a minimal launcher for my Hyperland setup, which presented some intriguing challenges related more to Wayland than the library itself. With a mix of clever window flags, absolute positioning, and careful sizing, I managed to create a “floating” window that escaped Hyperland’s tiling behavior. Thankfully, libqt6zig is robust enough that I didn’t need to manipulate XCB or wlroots directly. The bindings handled everything for me, which made the process far smoother, though it required some trial and error.

During these experiments, I also felt the absence of features like generics and compile-time reflection, which would have allowed for cleaner, more type-safe abstractions. While Zig does offer comptime capabilities, I couldn’t quite achieve what I envisioned. I also missed having access to a QTNativeWindow abstraction, which would have simplified certain window management tasks. These limitations stem more from the current state of the bindings than from Qt itself. I’ve discussed these points with the library’s author, who is aware and might implement them in the future. Until then, patience is key. We’re benefiting from the dedication of a single maintainer producing high-quality, low-level bindings for Zig.

Reflections on the Library

Working with libqt6zig was an eye-opening experience. Right from the start, I was impressed by how faithfully it exposes Qt’s C++ API while keeping the interface accessible to Zig developers. The library is surprisingly complete, covering most of the widgets, layouts, and common functionality you would expect from a typical Qt project. Despite being maintained by a single developer, the bindings are robust and consistent, which made experimentation smooth and enjoyable.

One thing that stood out is how much control you get over the GUI elements. Every widget, layout, and property is explicit, which forces you to think about your UI structure carefully. Unlike higher-level frameworks that abstract away the details, libqt6zig lets you handle memory management, widget hierarchies, and layout logic directly. This level of control can be intimidating at first, but it quickly becomes empowering once you get used to it. You feel like you are working with the core of the system rather than relying on layers of abstraction.

At the same time, the library has some limitations. Working with opaque pointers can feel risky because it removes compile-time type safety, and the lack of certain abstractions like generics or a QTNativeWindow wrapper means you occasionally need to write more boilerplate. However, these trade-offs are manageable, and the experience is educational. You learn not only how Qt works but also how to structure a cross-platform GUI application effectively in Zig.

Overall, my experience with libqt6zig was extremely positive. It made creating a fully functional shopping list application straightforward and even enjoyable. The library is well-documented, the API feels natural for Zig, and the bindings handle the low-level details so you can focus on building your application rather than wrestling with the underlying system. The potential for future improvements is exciting, and I look forward to seeing how the library evolves.

Conclusion

In conclusion, using Zig with libqt6zig provides a powerful combination for building cross-platform GUI applications. While it requires attention to memory management and pointer safety, the explicitness and control make it a rewarding experience. You can produce functional, responsive, and visually appealing applications with surprisingly little code.

For anyone interested in exploring GUI development in Zig, libqt6zig is an excellent starting point. It demonstrates that Zig can be used effectively beyond systems programming, opening the door to lightweight, high-performance desktop applications. The library is already impressive, and with continued development, it could become a go-to choice for Zig developers looking to build modern GUIs. My experiments with both the shopping list application and my Hyperland launcher showed that even complex interactions are achievable with patience and careful design. Overall, this experience reinforced my enthusiasm for Zig and its growing ecosystem, and it leaves me optimistic about the future of GUI development in this language.

References and Resources

If you want to explore libqt6zig yourself or learn more about the library and its author, here are some useful links:

Shopping List App Source Code – The complete source code for the shopping list application built in this article.
libqt6zig GitHub Repository – The library used for these experiments.
rcalixte GitHub Profile – The author and maintainer of libqt6zig.
Qt Documentation – Official Qt documentation for widgets, layouts, and styling.
Zig Programming Language – Learn more about Zig, its syntax, and features.
QSS Styling Guide – Qt's CSS-like styling system for widgets.

Exploring these resources will help you get started with Zig GUI development and allow you to dive deeper into creating more complex applications.

I Miss when Software Ended

Dayvster 🌊 — Thu, 16 Oct 2025 14:03:37 +0000

We used to ship software that ended

Remember when software had an end, like a movie or a book? You bought it, installed it, used it. There were no weekly updates, no monthly subscriptions, no constant notifications to update or accept frankly ever more intrusive permissions or ridiculous terms of service. Software was a product, not a service. You owned it, you controlled it. It was yours.

What Happened?

Somewhere along the way, software companies decided that they could make more money by turning software into a service. Instead of selling you a product, they would sell you a subscription. This meant that you would have to pay them every month or year to continue using their software. This also meant that they could update the software whenever they wanted.

Now in my honest opinion this was mostly a good thing, because it meant that software could be updated without much fuss, bugs and issues could be patched out and in the early days of SaaS you'd mostly get more value for your money, because you'd get new features and improvements without having to buy a new version of the software.

Back then when software was a full on product and delivery of updates was not as seamless as it is today, you'd often have to wait quite a while for a patch to get released and available for download or purchase via service packs or even worst case scenario new versions of the software. Think Photoshop 6 to Photoshop 7, or Windows XP to Windows Vista.

So SaaS did solve a really great problem there where you did not have to be locked to a certain version of the software with all it's bugs, issues, security flaws, or just lack of features.

When Updates Stopped feeling like progress

However over time the promise got blurry, updates stopped feeling like more value delivered to the end user and more like obligations to keep the service running. Updates became more frequent, more intrusive and more often than not they would break things rather than fix them.

Features quietly got removed, or hidden behind more premium paywalls so that companies could incentivize users to slowly upgrade to more expensive plans. Instead of delivering valuable updates or features SaaS was now used to fine tune companies revenue streams.

And at this point I was still okay with it, because as an end user I still got value for my money, it cost more money sure but the way most companies structured their plans it was negligible for most common users.

Can't fault a company for trying to make money off of their work right? As long as they pay their developers fairly and deliver a good product I don't see a problem with it.

But it still felt odd because we were essentially renting software rather than owning it, we no longer bought a product but rather a service that was completely in the hands of the provider and for a while that relationship was pretty fair and balanced.

The Subscription Model got out of hand

But then came the era of "everything subscription". Suddenly every single piece of software you used was a subscription. No matter how small or trivial the functionality was it would sooner or later succumb to the SaaS demon.

This is how we got simple things like Postman, Git clients, Email clients and in some extreme cases even very basic text editors that we suddenly had to pay a monthly fee to use.

This is where I started to feel uneasy about the whole SaaS model, because no longer did the value provided to the end user justify the cost of the subscription. Do you as a user really need all the features that the $14 a month postman plan provides? Or do you really need to pay $5 a month for a git client how about that $20 a month email client?

The price is not even my main problem, I want to support all of these companies and their developers, I want them to be able to make a living off of their work, but they do not offer me a way to pay them fairly.

All of the examples above have free tiers and then the next payed tier is a monthly subscription filled to the brim with stuff that I will very very rarely need.

I would love to be able to pay a one time fee of whatever their software is worth to them and I'd happily be locked at a certain version of their software that I can use for as long as I want. But I am not allowed to do that because the subscription model does not allow for it.

I have to either use the free tier or pay a monthly subscription filled with stuff that I do not really need or want.

But the worst part is yet to come.

Lack of Ownership means Lack of Control

This is where the SaaS model really starts to fall apart for me, because I no longer own the software I use. I’m merely renting it. And as a renter, I have no real control.

The software we rely on for our work, our hobbies, and sometimes even our ability to function day to day can be taken away at any time for any reason. A company can shut it down, change the pricing, or rewrite the terms of service overnight. If you don’t like it, you’re out.

In some extreme cases, users have been forced to waive their basic consumer rights just to keep using software or the hardware it runs on. Disney, for instance, once argued in court that by using their streaming service you agreed not to sue them even if they acted illegally or unethically. They actually tried to use that argument to dodge a lawsuit from a man whose wife died in Disneyland after an allergic reaction, even though the staff had been warned about her allergy.

That’s the level of power imbalance we’ve created. Software you rent can demand that you accept terms that are questionable at best and dangerous at worst, and your only alternative is to lose access to something you depend on.

This is not what SaaS was meant to be. The original idea was to deliver more value, not to take away control or ownership. SaaS should have evolved into a model of better service, not deeper dependency.

And now, there’s a new layer to it. Companies like Adobe and Notion quietly use your work, your data, and your creations to train their AI models. All justified by a single line in an update that you “agreed” to when you clicked through just to get back to work.

That’s not progress. That’s permission laundering.

So where does this leave us? Somewhere between the promise SaaS once held and the reality many of us experience today. The model itself isn’t broken, but the way it’s often applied is. Updates, subscriptions, and cloud features should be tools to deliver value, not mechanisms to extract it.

Maybe the answer isn’t abandoning SaaS entirely. Maybe it’s building a model that respects both the user and the developer, giving people choice, stability, and control while still funding ongoing improvements.

A Third More Reasonable Way?

There’s a middle ground that gets mostly ignored in today’s software landscape. It’s simple: give users choice. Let people decide how they want to interact with your product.

Some users are perfectly fine renting access, staying on the bleeding edge, and paying for convenience. Others just want to own the software they rely on, lock in a version, and use it indefinitely without worrying about subscriptions, sudden paywalls, or disappearing features.

Imagine a model where the same software offers both paths:

A one-time purchase option for users who are happy to stay on version X. No forced upgrades. No subscription. Just a finished product they can control.

A subscription option for users who want continuous updates, cloud features, and new tools as soon as they’re ready.

This approach respects both sides. It honors the nostalgic value of software as a finished product while keeping the benefits of SaaS alive. Users get what they need, developers get paid fairly, and everyone keeps a sense of control.

It’s not about rejecting SaaS. It’s about rebalancing it. Making updates and subscriptions tools for value, not leverage. Let people pay for what they actually want, and stop using access as a weapon.

Software can still evolve. SaaS can still be great. But it doesn’t have to come at the cost of ownership, autonomy, or trust.

This approach isn’t just about giving people options. It’s about returning control to the users, respecting the work they create, and protecting their data. Ownership and privacy aren’t optional features, they are the foundation of trust between software and the people who rely on it.

Reclaiming What’s Ours

Software belongs to the people who bought it. Full stop. We should control our tools, our work, and our data without being coerced or trapped by subscriptions, paywalls, or shady terms. Ownership and privacy are not optional conveniences, they are fundamental rights.

I am asking for a software world where users are not just passive consumers. Let us own what we create. Let us decide if we want to stay on a version indefinitely or pay for updates on our terms. Let companies innovate without taking control from the people who depend on their products.

This is not a plea for nostalgia. It is a demand for respect, trust, and autonomy. SaaS can be powerful, but it must not come at the cost of ownership or privacy. Users deserve tools that serve them, not cages disguised as convenience.

Moving Forward

We don’t have to accept a software landscape where ownership, control, and privacy are optional. Developers and users can coexist in a fairer ecosystem, one where innovation thrives without taking advantage of those who rely on the software.

If you’re a developer, consider offering choice. Let users pay for updates if they want them, but don’t trap those who are happy with a stable version. Respect the work your users create and give them control over their data.

If you’re a user, don’t settle for losing ownership. Support companies that value transparency, respect privacy, and give you options. Demand software that works for you, not against you.

SaaS can still be powerful, flexible, and convenient. But it should serve the people who use it, not turn them into passive renters of their own tools. Let’s build a future where software ends gracefully, respectfully, and on our terms, while still evolving for those who want it to.

Accidentally Made a Zig dotenv Parser

Dayvster 🌊 — Tue, 07 Oct 2025 19:00:00 +0000

Recently I've made a Zig based CLI argument parser called argh I've even written myself a roadmap I'd like to follow with this project. And so far I have been following it pretty well. However last week I began working on the next item on my roadmap which was to add support for environment variables to the arg parser, where you could set an environment variable to set the value of a flag.

Not many use cases for it I know it's more of an edge case but I thought it would be a fun exercise to implement that. So I started working on it. I carefully scaffolded out the feature what functions I'd like to see in it how they should behave what guard rails I'd like to set to ensure type safety, memory safety, and so on.

As I was implementing all the things I scaffolded out one by one I realized that I was basically writing a fully fledged dotenv parser. And I thought to myself "hey this is pretty cool I should probably make this a separate library so other people can use it too" and it's not deeply coupled to the arg parser so it makes sense to do that. So I did. I extracted the code out into its own repository called zdotenv.

The Library

The dotenv parser itself is pretty simple to use and I've even provided a basic example and tests in my repository that you can check out to see how it works. But regardless here's a quick example of how to use it:

const std = @import("std");
const Dotenv = @import("dotenv").Dotenv;

pub fn main() !void {
    const allocator = std.heap.page_allocator;
    var dotenv = Dotenv.init(allocator);
    defer dotenv.deinit();
    try dotenv.load(&[_][]const u8{"./examples/example.env"});
    if (dotenv.get("FOO")) |val| {
        std.debug.print("FOO={s}\n", .{val});
    } else {
        std.debug.print("FOO not found\n", .{});
    }
}

This will load the environment variables from the specified file and you can then access them using the get method. The load method takes an array of file paths so you can load multiple dotenv files if you want to.

That's it, that's all there is to it. It's simple and straightforward as a dotenv parser should ideally be.

I've also added support for specifying custom .env file names since not everyone uses the default .env file all the time, you may wanna dynamically load different env files based on the environment you're in (development, staging, production, etc).

I've added support for comments, blank lines and values in double quotes. So it should cover most use cases out there.

Features

Loads key-value pairs from .env basically the core feature it does that it says, it parses an .env file and loads the key-value pairs into memory so that you can access them later via the get method.
Supports comments and blank lines it ignores comments and blank lines so you can have a well formatted .env file without any issues.
Provides easy access to values via hash map you can access the values using the get method which returns an optional value so you can handle the case where the key doesn't exist. I picked a hash map for this since generally speaking your .env files won't ever be that large so we can just store them in memory for easy and fast access.
Memory safe all allocations are freed with a deinit method so you don't have to worry about memory leaks.

Conclusion

Well that's it for now. I'll be adding additional functionality and patches to the library as I see fit. But for now it's a pretty solid and usable dotenv parser that you can use in your Zig projects. I for one have already used it in my notes CLI application I made a while back to compare Zig against Rust and it works like a charm.

As always I welcome contributions and feedback so if you have any ideas or suggestions feel free to open an issue or a pull request on the repository.

And if you have any questions or would like to reach out to me you can find me on Twitter

Is Odin Just a More Boring C

Dayvster 🌊 — Sat, 04 Oct 2025 15:21:49 +0000

Why I Tried Odin

Background

My recent posts have been diving deep into Zig and C, a shift from my earlier focus on React and JavaScript. This isn’t a pivot but a return to my roots. I started programming at 13 with C and C++, and over the years, I’ve built a wide range of projects in systems programming languages like C, C++, Rust, and now Zig. From hobby experiments and custom Linux utilities to professional embedded systems work think vehicle infotainment, tracking solutions, and low-level components I’ve always been drawn to the power and precision of systems programming. Alongside this, I’ve crafted tools for my own environment and tackled plenty of backend engineering, blending my full-stack expertise with a passion for low-level control.

Why Odin Caught My Eye

I like many others initially dismissed Odin as that language that was primarily intended for game development. It took me a moment or should I say many moments to realize just how stupid that notion was. Because let's analyze what game development actually means, it means building complex systems that need to be efficient, performant and reliable. It means working with graphics, physics, input handling, networking and more. It means dealing with concurrency, memory management and low level optimizations. In other words, game development is a perfect fit for a systems programming language like Odin.

So basically if it's intended for game development, then it should be a great fit for general systems programming, desktop applications and since game dev usually means manual memory management without a garbage collector, it should also be possible to some extent to use it for embedded systems.

So after I've gave myself a good slap on the forehead for being a bit of an idiot. I decided why not give Odin a fair shot and build something useful with it.

The Project

Now I may have been a bit liberal with the word useful there, what I actually decided to build was something that I usually like to build whenever I wanna try out a new language, namely a tiny key-value store with a pub/sub system. It won't win any awards for originality and I'm pretty sure the folks over at redis aren't exactly shaking in their boots. It is the most basic most barebones implementation of both lacking any real useful features that would make it usable in a production environment. But it is a good exercise in understanding the language and its capabilities.

Mainly because it involves a few different aspects of programming that are relevant to systems programming. It involves data structures, memory management, concurrency and networking.

And even if you create something as basic and lacking as I have in this example, you still have room for experimentation and exploration to add more features.

Building a Tiny KV Store With Pub/Sub

My initial minimal proof of concept was simple and straightforward.

package main

import "core:fmt"
import "core:time"

KVStore :: struct {
    store: map[string]string,
}

kvstore_init :: proc() -> KVStore {
    return KVStore{store = map[string]string{}}
}

kv_put :: proc(kv: ^KVStore, key: string, value: string) {
    kv.store[key] = value
}

kv_get :: proc(kv: ^KVStore, key: string) -> string {
    if value, ok := kv.store[key]; ok {
        return value
    }
    return ""
}

PubSub :: struct {
    subscribers: map[string][]proc(msg: string),
}

pubsub_init :: proc() -> PubSub {
    return PubSub{subscribers = map[string][]proc(msg: string){}}
}

subscribe :: proc(ps: ^PubSub, topic: string, handler: proc(msg: string)) {
    if arr, ok := ps.subscribers[topic]; ok {
        new_arr := make([]proc(msg: string), len(arr)+1);
        for i in 0..<len(arr) {
            new_arr[i] = arr[i];
        }
        new_arr[len(arr)] = handler;
        ps.subscribers[topic] = new_arr;
    } else {
        ps.subscribers[topic] = []proc(msg: string){handler};
    }
}

publish :: proc(ps: ^PubSub, topic: string, msg: string) {
    if handlers, ok := ps.subscribers[topic]; ok {
        for handler in handlers {
            handler(msg);
        }
    }
}

kv: KVStore;

main :: proc() {
    kv = kvstore_init();
    ps := pubsub_init();

    handler1 :: proc(msg: string) {
        fmt.println("Sub1 got:", msg);
        kv_put(&kv, "last_msg", msg);
    }

    handler2 :: proc(msg: string) {
        fmt.println("Sub2 got:", msg);
    }

    handler3 :: proc(msg: string) {
        fmt.println("Sub3 got:", msg);
    }

    subscribe(&ps, "demo", handler1);
    subscribe(&ps, "demo", handler2);
    subscribe(&ps, "demo", handler3);

    publish(&ps, "demo", "Welcome to dayvster.com");

    time.sleep(2 * time.Second);
    publish(&ps, "demo", "Here's another message after 2 seconds");

    last := kv_get(&kv, "last_msg");
    fmt.println("Last in kvstore:", last);
}

As you can see it currently lacks any real error handling, concurrency and persistence. But it does demonstrate the basic functionality of a key-value store with pub/sub capabilities. What I have done is created two main structures, KVStore and PubSub. The KVStore structure contains a map to store key-value pairs and provides functions to put and get values. The PubSub structure contains a map of subscribers for different topics and provides functions to subscribe to topics and publish messages.

The main function initializes the key-value store and pub/sub system, defines a few handlers for incoming messages, subscribes them to a topic, and then publishes some messages to demonstrate the functionality.

From this basic example we've explored how to handle memory management in Odin, how to work with data structures like maps and slices, and how to define and use procedures.

Memory Management

Like C and Zig, Odin employs manual memory management, but it offers user-friendly utilities to streamline the process, much like Zig, in contrast to C’s more rudimentary approach. For instance, the make function in Odin enables the creation of slices with a defined length and capacity, akin to Zig’s slice allocation. In the code above, make([]proc(msg: string), len(arr)+1) generates a slice of procedure pointers with a length of len(arr)+1. Essentially, it allocates memory on the heap and returns a slice header, which includes a pointer to the allocated memory, along with the length and capacity of the slice.

but how and when is that memory freed? In this code, memory allocated by make (e.g., for the slice in subscribe) and for maps (e.g., kv.store and ps.subscribers) is not explicitly freed. Since this is a short-lived program, the memory is reclaimed by the operating system when the program exits. However, in a long-running application, you’d need to use Odin’s delete procedure to free slices and maps explicitly. For example:


kvstore_deinit :: proc(kv: ^KVStore) {
    delete(kv.store);
}

pubsub_deinit :: proc(ps: ^PubSub) {
    for topic, handlers in ps.subscribers {
        delete(handlers);
    }
    delete(ps.subscribers);
}

So let's add that in the main function before it exits to ensure we clean up properly:

// ... existing code ...
main :: proc() {
    // ... existing code ...
    pubsub_deinit(&ps);
    kvstore_deinit(&kv);
} // end of main

Well would you look at that, we just added proper memory management to our tiny KV store with pub/sub system and all it took was a few lines of code. I'm still a huge fan of C but this does feel nice and clean, not to mention really readable and easy to understand.

Is our code now perfect and fully memory safe? Not quite, it still needs error handling and thread safety(way later) for production use, but it’s a solid step toward responsible memory management.

Adding concurrency

Enhancing Pub/Sub with Concurrency in Odin

To make our pub/sub system more realistic, we've introduced concurrency to the publish procedure using Odin's core:thread library. This allows subscribers to process messages simultaneously, mimicking real-world pub/sub behavior. Since handler1 modifies kv.store via kv_put, we've added a mutex to KVStore to ensure thread-safe access to the shared map. Here's how it works:

Concurrent Execution with Threads: The publish procedure now runs each handler in a separate thread created with thread.create. Each thread receives the handler and message via t.user_args, and thread.start kicks off execution. Threads are collected in a dynamic array (threads), which is cleaned up using defer delete(threads). The thread.join call ensures the program waits for all threads to finish, and thread.destroy frees thread resources. This setup enables handler1, handler2, and handler3 to process messages concurrently, with output order varying based on thread scheduling.
Thread Safety with Mutex: Since handler1 updates kv.store via kv_put, concurrent access could lead to race conditions, as Odin's maps aren't inherently thread-safe. To address this, a sync.Mutex is added to KVStore. The kv_put and kv_get procedures lock the mutex during map access, ensuring only one thread modifies or reads kv.store at a time. The mutex is initialized in kvstore_init and destroyed in kvstore_deinit.

publish :: proc(ps: ^PubSub, topic: string, msg: string) {
    if handlers, ok := ps.subscribers[topic]; ok {
        threads := make([dynamic]^thread.Thread, 0, len(handlers))
        defer delete(threads)

        // Allocate ThreadArgs for each handler
        thread_args := make([dynamic]^ThreadArgs, 0, len(handlers))
        defer {
            for args in thread_args {
                free(args)
            }
            delete(thread_args)
        }

        for handler in handlers {
            msg_ptr := new(string)
            msg_ptr^ = msg
            t := thread.create(proc(t: ^thread.Thread) {
                handler := cast(proc(msg: string)) t.user_args[0]
                msg_ptr := cast(^string) t.user_args[1]
                handler(msg_ptr^)
                free(msg_ptr)
            })
            t.user_args[0] = rawptr(handler)
            t.user_args[1] = rawptr(msg_ptr)
            thread.start(t)
            append(&threads, t)
        }

        for t in threads {
            thread.join(t)
            thread.destroy(t)
        }
    }
}

This implementation adds concurrency by running each handler in its own thread, allowing parallel message processing. The mutex ensures thread safety for kv.store updates in handler1, preventing race conditions. Odin's core:thread library simplifies thread management, offering a clean, pthread-like experience.

Odin’s threading feels like a bit like C’s pthreads but without the usual headache, and it’s honestly a breeze to read and write. For this demo, the mutex version keeps everything nice and tidy, However in a real application, you'd still want to consider more robust error handling and possibly a thread pool for efficiency and also some way to handle thread lifecycle and errors and so on...

Adding Persistence

I haven't added persistence to this code-block personally because I feel that would quickly spiral the demo that I wanted to keep simple and focused into something much more complex. But if you wanted to add persistence, you could use Odin's core:file library to read and write the kv.store map to a file. You would need to serialize the map to a string format (like JSON or CSV) when saving and deserialize it when loading. Luckily odin has core:encoding/json and core:encoding/csv libraries that can help with this. Which should at the very least make that step fairly trivial.

So if you feel like it, give it a shot and let me know how it goes. Do note that this step is a lot harder than it may seem especially if you want to do it properly and performantly.

Now to Compile and Run

Now here's the thing the first time I ran odin build . I thought I messed up somewhere because, it basically took a split second and produced no output no warnings no nothing. But I did see that a binary was produced named after the folder I was in. So I ran it with

❯ ./kvpub
Sub1 got: Welcome to dayvster.com
Sub2 got: Welcome to dayvster.com
Sub3 got: Welcome to dayvster.com
Sub1 got: Here's another message after 2 seconds
Sub2 got: Here's another message after 2 seconds
Sub3 got: Here's another message after 2 seconds
Last in kvstore: Here's another message after 2 seconds

And there you have it, a tiny key-value store with pub/sub capabilities built in Odin. That compiled bizarrely fast, in fact I used a util (pulse) I wrote to benchmark processes and their execution time and it clocked in at a blazing 0.4 seconds to compile

❯ pulse --benchmark --cmd 'odin build .' --runs 3

┌──────────────┬──────┬─────────┬─────────┬─────────┬───────────┬────────────┐
│ Command      ┆ Runs ┆ Avg (s) ┆ Min (s) ┆ Max (s) ┆ Max CPU%  ┆ Max RAM MB │
╞══════════════╪══════╪═════════╪═════════╪═════════╪═══════════╪════════════╡
│ odin build . ┆ 3    ┆ 0.401   ┆ 0.401   ┆ 0.401   ┆ 0.00      ┆ 0.00       │
└──────────────┴──────┴─────────┴─────────┴─────────┴───────────┴────────────┘

Well I couldn't believe that so I ran it again this time with --runs 16 to get a better average and it still came in at a very respectable 0.45 (MAX) seconds.

OK that is pretty impressive. but consistent maybe my tool is broken? I'm not infallible after all. So I re-confirmed it why hyperfine and it came out at:

❯ hyperfine "odin build ."
Benchmark 1: odin build .
  Time (mean ± σ):     385.1 ms ±  12.5 ms    [User: 847.1 ms, System: 354.6 ms]
  Range (min … max):   357.3 ms … 400.1 ms    10 runs

God damn that is fast, now I know the program is tiny and simple but still that is impressive and makes me wonder how it would handle a larger codebase. Please if you have any feedback or insights on this let me know I am really curious.

just for sanitysake I also ran time odin build . and it came out at you've guessed it 0.4 seconds.

Right so it's fast, but how's the experience?

Well I have to say it was pretty smooth overall. The compiler is fast and the error messages are generally clear and helpful if not perhaps a bit... verbose for my taste

For example I've intentionally introduced a simple typo in the map keyword and named is masp to showcase what I mean:

❯ odin build .
/home/dave/Workspace/TMP/odinest/main.odin(44:31) Error: Expected an operand, got ]
        subscribers: masp[string][]proc(msg: string),
                                  ^
/home/dave/Workspace/TMP/odinest/main.odin(44:32) Syntax Error: Expected '}', got 'proc'
        subscribers: masp[string][]proc(msg: string),
                                   ^
/home/dave/Workspace/TMP/odinest/main.odin(44:40) Syntax Error: Expected ')', got ':'
        subscribers: masp[string][]proc(msg: string),
                                           ^
/home/dave/Workspace/TMP/odinest/main.odin(44:41) Syntax Error: Expected ';', got identifier
        subscribers: masp[string][]proc(msg: string),
                                            ^

I chose specifically this map because I wanted to showcase how Odin handles errors when you try to build, it could simply say Error: Unknown type 'masp' but instead it goes on to produce 4 separate errors that all stem from the same root cause. This is obviously because the parser gets confused and can't make sense of the code anymore. So essentially you get every single error that results from the initial mistake even if they are on the same line. Now would I love to see them condensed into a single error message? Because it stems from the same line and the same root cause? Yes I would. But that's just my personal preference.

Where Odin Shines

Simplicity and Readability

Odin kinda feels like a modernized somehow even more boring C but in the best way possible. It's simple, straightforward and easy to read. It does not try to have some sort of clever syntax or fancy features, it really feels like a no-nonsense no frills language that wants you to start coding and being productive as quickly as possible.

In fact this brings me to my next point.

The Built in Libraries Galore

I was frankly blown away with just how much is included in the standard and vendored(more on that later) libraries. I mean it has everything you'd expect from a modern systems programming language but it also comes with a ton of complete data structures, algorithms and utilities that you would usually have to rely on third-party libraries for in C or even Zig.

For more info just look at Odin's Core Library and I mean really look at it and read it do not just skim it. Here's an example flags which is a complete command line argument parser, or even rbtree which is a complete implementation of a red-black tree data structure that you can just import and use right away

But what really blew me away was

The Built in Vendor Libraries / Packages

Odin comes with a set of vendor libraries that basically give you useful bindings to stuff like SDL2/3, OpenGL, Vulkan, Raylib, DirectX and more. This is really impressive because it means you can start building games or graphics applications right away without having to worry about setting up bindings or dealing with C interop. Now I'm not super sure if these vendor bindings are all maintained and created by the Odin team from what I could gather so far, it would certainly seem so but I could be wrong. If you know more about this please let me know.

But all that aside these bindings are really well done and easy to use. For example here's how you can create a simple window with SDL2 in Odin:

package main

import sdl "vendor:sdl2"

main :: proc() {
    sdl.Init(sdl.INIT_VIDEO)
    defer sdl.Quit()

    window := sdl.CreateWindow(
        "Odin SDL2 Black Window",
        sdl.WINDOWPOS_CENTERED,
        sdl.WINDOWPOS_CENTERED,
        800,
        600,
        sdl.WINDOW_SHOWN,
    )
    defer sdl.DestroyWindow(window)

    renderer := sdl.CreateRenderer(window, -1, sdl.RENDERER_ACCELERATED)
    defer sdl.DestroyRenderer(renderer)

    event: sdl.Event
    running := true
    for running {
        for sdl.PollEvent(&event) {
            if event.type == sdl.EventType.QUIT {
                running = false
            }
        }

        sdl.SetRenderDrawColor(renderer, 0, 0, 0, 255) 
        sdl.RenderClear(renderer) 
        sdl.RenderPresent(renderer) 
    }
}

This code creates a simple window with a black background using SDL2. It's pretty straightforward and easy to understand, especially if you're already familiar with SDL2 or SDL3.

C Interop

Odin makes it trivially easy to interop with C libraries, as long as that. This is done via their foreign import where you'd create an import name and link to the library file and foreign blocks to link to declared individual function or types.

I could explain it with examples here but Odin's own documentation does a way better job and will keep this post from getting even longer than it already is. So please check out Odin's C interop documentation for more info.

Where Odin Feels Awkward

Standard Library Gaps

While Odin's standard library is quite comprehensive, there are still some gaps and missing features that can make certain tasks more cumbersome. For example, while it has basic file I/O capabilities, it lacks more advanced features like file watching or asynchronous I/O. Additionally, while it has a decent set of data structures, it lacks some more specialized ones like tries or bloom filters I'd also love to see a b+ tree implementation in the core library.

But those are at most nitpicks and finding third-party libraries or writing your own implementations is usually straightforward.

However...

No Package Manager

I really like languages that come with their own package manager, it makes it so much easier to discover, install and manage third-party libraries / dependencies. Odin currently lacks a built-in package manager, which means you have to manually download and include third-party libraries in your projects. This can be a bit of a hassle, especially I'd imagine for larger projects with multiple dependencies.

Smaller Nitpicks

dir inconsistencies: I love how it auto named my binary after the folder I was in but I wish it did the same whenever I ran odin run and odin build I had to explicitly specify odin run . and odin build . that felt a bit inconsistent to me because if it knows the folder we are in why not just use that as the default value when we wanna tell it to run or build in the current directory?
Error messages: As mentioned earlier, while Odin's error messages are generally clear, they can sometimes be overly verbose, especially when multiple errors stem from a single root cause. It would be nice to see more concise error reporting in such cases.

So to fix this I'd love to either see error messages collapsed into a single message with an array of messages from the same line, or somehow grouped together into blocks.

Pointers are ^ and not *

I'm on a German keyboard and the ^ character is a bit of a pain to type, especially when compared to the * character which is right next to the Enter key on my keyboard. I get that Odin wants to differentiate itself from C and C++ but this small change feels unnecessary and adds a bit of friction to the coding experience.

These are as the title says just minor nitpicks and in no way detract from the overall experience of using Odin, just minor annoyances that I personally had while using the language your experience may differ vastly and none of these may even bother you.

So is Odin just a More Boring C?

In a way, yes kind of. I mean it's very similar in approach and philosophy but with more "guard rails" and helpful utilities to make the experience smoother and more enjoyable and the what I so far assume are first party bindings to popular libraries via the vendors package really makes it stand out in a great way, where you get a lot more consistency and predictability than you would if you were to use C with those same libraries.

And I guess that's the strength of Odin, it's so boring that it just let's you be a productive programmer without getting in your way or trying to be too clever or fancy.

I use boring here in an affectionate way, if you've ever read any of my other posts you'll know that I do not appreciate complexity and unnecessary cleverness in programming which is why I suppose I'm often quite critical of rust even though I do like it for certain use cases.

In this case I'd say Odin is very similar to Go both are fantastic boring languages that let you get stuff done without much fuss or hassle. The only difference is that Go decided to ship with a garbage collector and Odin did not, which honestly for me personally makes Odin vastly more appealing.

Syntax and Ergonomics

Odin’s syntax is like C with a modern makeover clean, readable, and less prone to boilerplate. It did take me quite a while to get used to replacing my muscle memory for * with ^ for pointers and func, fn, fun, function with proc for functions. But once I got over that initial hump, it felt pretty natural.

Also :: for type declarations is a bit unusual and took me longer than I care to admit, as I'm fairly used to :: being used for scope resolution in languages like C++ and Rust. But again, once I got used to it, it felt fine.

Everything else about the syntax felt pretty intuitive and straightforward.

Who Odin Might Be Right For

Ideal Use Cases

Game Development: Honestly I totally see where people are coming from when they say Odin is great for game development. The built-in vendor libraries for SDL2/3, OpenGL, Vulkan, Raylib and more make it super easy to get started with game development. Plus the language's performance and low-level capabilities are a great fit for the demands of game programming.
Systems Programming: Odin's manual memory management, low-level access, and performance make it a solid choice for systems programming tasks like writing operating systems, device drivers, or embedded systems.
I will absolutely be writing some utilities for my Linux setup in Odin in the near future.
Desktop Applications: Again this is where those vendor libraries shine, making it easy to build cross-platform desktop applications with graphical interfaces as long as you're fine with doing some manual drawing of components, I'd love to see a binding for something like GTK or Qt in the vendor packages in the future.
General Purpose Programming: This brings me back to my intro where I said that it took me a while to realize that if Odin is good for game development then realistically by all means it should basically be good for anything and everything you wish to create with it. So yea give it a shot make something cool with it.

Where It’s Not a Good Fit Yet

Web Development: The Net library is pretty darn nice and very extensive, however it does seem like it's maybe a bit more fit for general networking tasks rather than simplifying your life as a web backend developer. I'm sure there's already a bunch of third party libraries for this, but if you're a web dev you are almost spoiled for choice at the moment by languages that support web development out of the box with all the fixings and doodads.

Final Thoughts

Would I Use It Again?

Absolutely in fact I will, I've already started planning some small utilities for my Linux setup in Odin. I really like the simplicity and readability of the language, as well as the comprehensive standard and vendor libraries. The performance is also impressive, especially the fast compile times.

Source Code and Feedback

You can find the complete source code for the tiny key-value store with pub/sub capabilities on my GitHub: dayvster/odin-kvpub

If you create anything cool with it I'd love to see it so do hit me up on any of my socials.

I'd love to hear your thoughts and experiences with Odin, whether you've used it before or are considering giving it a try. Feel free to leave a comment or reach out to me on Twitter @dayvster.

Appreciate the time you took to read this post, and happy coding!

My Battle Tested React Hooks Are Now Open Source

Dayvster 🌊 — Thu, 02 Oct 2025 14:53:23 +0000

Don't yap just give me the links

Ok I get it you're busy here you go:

Have a great day!

What's This?

I've been developing react since 2013 it's been through a lot of changes and updates over the years. We've seen patterns come and go, however when hooks were introduced in 2019, I was instantly ... hooked. No wait please don't leave, that was a good joke and you know it!

Anyhow now that that's out of the way, I wanted to share with you a collection of various hooks that I have written over and over and over again in my past projects. These hooks have been battle tested in production applications and multiple client, personal and professional projects.

Why Open Source?

Well I have this post on my blog about why I believe everyone should open source their work, Open Source Your Projects I've been recently redesigning my website and fixing up my old blog posts and I stumbled upon this one decided to re-read it fully and discovered I am a hypocrite by value of pure laziness.

Yes I did not open source these hooks sooner, because I was simply lazy. I had them in various different projects, repos, side projects etc. etc. But I never took the time to actually put them together in a single package and publish it. I just kept either navigating to these projects and constantly copy pasting them around OR worse yet I would rewrite them from scratch every time I needed them, which is just plain dumb.

So I decided to stop being a hypocrite and finally open source a bunch of my stuff part of that was the task of collecting all of these react hooks and putting them together in a single package.

So here it is

Introducing React-Kata

React-Kata is a collection of battle-tested React hooks that I've used in various projects over the years. These hooks are designed to make your life easier and help you write cleaner, more efficient code.

Why React-Kata?

Kata is a term used in martial arts to describe a set of movements and techniques that are practiced repeatedly to improve skill and mastery. Similarly, React-Kata is a collection of hooks that I've rewritten and reused and refined over and over again. So I thought it would be appropriate to name it React-Kata. Also I did martial arts as a younger person and wanted to show off a bit, lay off.

Examples:

useLocalStorage: A hook that makes it easy to work with local storage in your React applications.
useDebounce: A hook that debounces a value, making it easier to work with user input and avoid unnecessary re-renders.
useThrottle: A hook that throttles a value, making it easier to work with user input and avoid unnecessary re-renders.
useTimeout: A hook that makes it easy to work with timeouts in your React applications.
useInterval: A hook that makes it easy to work with intervals in your React applications
useSessionStorage: A hook that makes it easy to work with session storage in your React applications.

and many many more in fact to see a lot of all of them check out the GitHub Repo Hooks overview

Code Examples

useShimmer

This hook generates a shimmer effect SVG that can be used as a placeholder while content is loading. It takes width and height as parameters and returns an SVG string.

import { useShimmer } from 'react-kata';

function ShimmerDemo() {
  const shimmer = useShimmer(400, 300);
  return <img src={`data:image/svg+xml;utf8,${encodeURIComponent(shimmer)}`} alt="Loading..." />;
}

useWhyDidYouUpdate

This hook helps you identify why a component re-rendered by logging the changed props to the console or handling them with a custom callback.

I can not overstate how often this one has saved my ass in the past.

import React, { useState } from 'react';
import { useWhyDidYouUpdate } from 'react-kata';

function Demo(props) {
  // Logs changed props to console by default
  useWhyDidYouUpdate('Demo', props);
  // Or provide a callback to handle changes
  useWhyDidYouUpdate('Demo', props, changedProps => {
    // Custom handling, e.g. send to analytics
    alert('Changed: ' + JSON.stringify(changedProps));
  });
  return <div>{props.value}</div>;
}

useTheme

Let's you simply manage themes in your application. Supports auto, light, dark, and custom themes.
For custom themes you simply input the name of the theme and it will be applied as the data-theme attribute on the html element.

It will also be stored in local storage and retrieved from local storage on page load.

import React from 'react';
import { useTheme } from 'react-kata';

function Demo() {
  // Supports auto, light, dark, and custom themes
  const [theme, setTheme, toggleTheme] = useTheme(["auto", "light", "dark", "solarized"]);
  return (
    <div>
      <span>Current theme: {theme}</span>
      <button onClick={toggleTheme}>Toggle Theme</button>
      <button onClick={() => setTheme("solarized")}>Solarized</button>
      <button onClick={() => setTheme("auto")}>Auto</button>
    </div>
  );
}

useReload

Allows you to pass a custom condition that when met will trigger a page reload.

import React from 'react';
import { useReload } from 'react-kata';

function Demo() {
  // Only reload if user confirms
  const reload = useReload(() => window.confirm('Reload?'));
  return <button onClick={reload}>Reload Page</button>;
}

Conclusion

I hope you find these hooks as useful as I have. If you have any suggestions for new hooks or improvements to existing ones, please feel free to open an issue or submit a pull request on GitHub, I'll always appreciate feedback, criticism, suggestions and especially Pull Requests.

Happy coding!

Why Zig Feels More Practical Than Rust for Real-World CLI Tools

Dayvster 🌊 — Tue, 23 Sep 2025 09:59:39 +0000

Introduction

So when it comes to memory management there are two terms you really need to know, the stack and the heap.

The stack is a region of memory that stores temporary data that is only needed for a short period of time. It operates in a last-in, first-out (LIFO) manner, meaning that the most recently added data is the first to be removed, as the name suggests. Basically imagine a stack of plates, if you wanna remove one plate you remove the top one, remove the middle plate and disaster awaits in this analogy. The stack is typically used for storing function parameters, local variables, and return addresses. It is fast and efficient because it has a fixed size and does not require dynamic memory allocation.

The size of the stack is usually limited, and if a program tries to use more stack space than is available, it can result in a stack overflow error. This can happen if a function calls itself recursively too many times or if a program allocates too much memory on the stack.

Whereas the heap as the name suggests is a region of memory that is used for dynamic memory allocation. Unlike the stack, the heap does not have a fixed size and can grow or shrink as needed. The heap is typically used for storing data that needs to persist beyond the lifetime of a single function call, such as objects or data structures that are created at runtime. Imagine the heap as a pile of clothes in a disorganized household, you can add or remove clothes as needed and as long as the pile isn't too big you can find what you need with relative speed and ease. But it will quickly become a nightmare if you let it grow out of control. The heap is managed by the operating system and requires dynamic memory allocation, which can be slower and less efficient than stack allocation.

The heap can also become fragmented over time, since we do not always store data in a contiguous block of memory. This can lead to performance issues and make it more difficult to allocate large blocks of memory.

Rust's Borrow Checker

Rust's borrow checker is a a pretty powerful tool that helps ensure memory safety during compile time. It enforces a set of rules that govern how references to data can be used, preventing common programming memory safety errors such as null pointer dereferencing, dangling pointers and so on. However you may have notice the word compile time in the previous sentence. Now if you got any experience at systems programming you will know that compile time and runtime are two very different things. Basically compile time is when your code is being translated into machine code that the computer can understand, while runtime is when the program is actually running and executing its instructions. The borrow checker operates during compile time, which means that it can only catch memory safety issues that can be determined statically, before the program is actually run.

This means that basically the borrow checker can only catch issues at comptime but it will not fix the underlying issue that is developers misunderstanding memory lifetimes or overcomplicated ownership. The compiler can only enforce the rules you’re trying to follow; it can’t teach you good patterns, and it won’t save you from bad design choices.

Story TIme

Last weekend I've made a simple CLI tool for myself to help me manage my notes it parses ~/.notes into a list of notes, then builds a tag index mapping strings to references into that list. Straightforward, right? Not in Rust. The borrow checker blocks you the moment you try to add a new note while also holding references to the existing ones. Mutability and borrowing collide, lifetimes show up, and suddenly you’re restructuring your code around the compiler instead of the actual problem.

In Zig, we would just allocate the list with an allocator, store pointers into it for the tag index, and mutate freely when we need to add or remove notes. No lifetimes, no extra wrappers, no compiler gymnastics, that’s a lot more straightforward.

But Dave isn't that the exact point of Rust's borrow checker?

Yes it is, however by using Zig I managed to get most of the benefits of Rust's memory safety without the complexity or ceremony of the borrow checker. All it took was some basic understanding of memory management and a bit of discipline. I was able to produce two CLI's that are both memory safe and efficient however the Zig one was way more straightforward and easier to reason about and took less time to write.

What is Safety, Really for CLI Tools?

This is where a lot of developers trip up, Rust markets itself as a language that produces safe software, great marketing hook, but one tiny problem, memory safety is one puzzle piece of overall software safety. I'm not sure if the Rust foundation does this on purpose sort of a blanket statement to make it seem like memory safety is the end all be all of software safety, or if they just don't want to constantly prefix safety with memory safety(even though they should).

But back to the main point, memory safety is just one aspect of software safety. You can argue if it's a big or small piece of the puzzle, I'd say it depends on the software and use-case but it's definitely not the only piece.

So What exactly is safety in terms of CLI tools?

Memory safety alone does not make a program safe. Your CLI tool can still crash, produce wrong results, corrupt files, leak sensitive data, be vulnerable to various types of attacks or just behave in a way that is not expected. Let's go back to my Notes CLI it's rust version may never segfault but it could silently overwrite my index or tags or corrupt my files if I make a mistake in my logic, or perhaps it could store my file in a temporary location that is world readable, exposing my notes to anyone on the system. Is that safe? No.

Would using Zig solve any of those issues automatically, also no.
Is my example a bit contrived, yes, but it illustrates the point that memory safety is not the only thing that matters when it comes to software safety.

In fact you should also consider other aspects of safety such as:

Predictable Behavior: The program should do what the user expects, even when input is malformed or unexpected. A CLI that panics on a missing file or fails silently on a corrupted note is not safe.
Avoiding Crashes or Silent Corruption: The program should handle errors gracefully, providing meaningful feedback to the user instead of crashing or corrupting data. A CLI that crashes on a malformed note or silently overwrites existing notes is not safe.
Manageable Performance: The program should perform well under expected workloads, avoiding excessive resource consumption or slowdowns. A CLI that becomes unresponsive when managing a large number of notes is not safe. This is where it really helps to understand memory allocations and performance characteristics of your language of choice.
Sensitive Data Handling: The program should protect sensitive data from unauthorized access or exposure. A CLI that stores notes in a world-readable temporary file is not safe.
Robustness Against Attacks: The program should be resilient against common attack vectors, such as injection attacks or buffer overflows. A CLI that can be exploited to execute arbitrary code or corrupt data is not safe. And this is precisely where Rust's memory safety shines, it can help prevent certain types of vulnerabilities that arise from memory mismanagement. However, it's not a silver bullet that guarantees overall safety.

The Borrow Checker: Strengths and Limitations

The borrow checker is impressive. It prevents dangling references, double frees, and mutable aliasing at compile time, things that would otherwise cause segfaults or undefined behavior. It’s why Rust can claim “memory safe without a garbage collector.”

Strengths:

Zero data races / mutable aliasing issues: The compiler guarantees that only one mutable reference exists at a time, and that immutable references cannot be combined with mutable ones.
Strong compile-time guarantees: Many memory-related bugs are caught before you even run the program.
Early bug detection: You find mistakes before shipping code, which is a huge win in long-lived services or concurrent systems.

Limitations / Pain Points:

Cognitive overhead: You’re constantly thinking about lifetimes, ownership, and borrow scopes, even for simple tasks. A small CLI like my notes tool suddenly feels like juggling hot potatoes.

Boilerplate and contortions: You end up introducing clones, wrappers (Rc, RefCell), or redesigning data structures just to satisfy the compiler. Your code starts serving the compiler, not the problem.

Compile-time only: The borrow checker cannot fix logic bugs, prevent silent corruption, or make your CLI behave predictably. It only ensures memory rules are followed.

Edge cases get messy: Shared caches, global state, or mutable indexes often trigger lifetime errors that are annoying to work around.

At this point, the Rust borrow checker can feel more like a mental tax than a helpful tool, especially for short-lived CLI projects. You’re trading developer ergonomics for a compile-time guarantee that, in many CLI scenarios, may be overkill.

Zig's Approach to Safety and Simplicity

Zig takes a different approach to safety and simplicity. It provides manual memory management with optional safety checks, allowing developers to choose the level of control they need. This can lead to more straightforward code for certain use cases, like CLI tools. However where it really shines is how it does manual memory management, I've briefly touched upon this in my other blog post Zig Allocators Explained.

But basically long story short Zig gives you allocators, a set of tools that helps you manually manage your memory in a more structured and predictable way. You can choose to use a general purpose allocator like the std.heap.page_allocator or you can create your own custom allocator that fits your specific needs. This allows you to have more control over how memory is allocated and deallocated, which can lead to more efficient and predictable memory usage. This combined with Zig's defer statement which allows you to schedule cleanup code to run when a scope is exited, makes it easy to manage resources gives you most of the power of Rust's borrow checker at your disposal without the complexity and ritual. However it asks one thing in return of you, discipline, your software will be only as safe as you make it. We can make the same claim about Rust, you can throw copy and clone and unsafe around your code and throw away all the benefits of the borrow checker in a heartbeat.

The two languages are polar opposites in this regard, Zig places the burden on the developer and makes it easy for them to produce memory safe software, whereas Rust places the burden on the compiler and makes it hard for developers to produce memory unsafe software.

Back to the main point, zig's approach to memory management is in my subjective opinion more practical for most of my use cases, especially for CLI tools. It allows me to write straightforward code that is easy to reason about and maintain, without the overhead of the borrow checker. I can allocate a list of notes, store pointers to them in a tag index, and mutate the list freely when I need to add or remove notes. No lifetimes, no extra wrappers, no compiler gymnastics, that’s a lot more straightforward.

Oh I almost forgot, Zig also has the comptime feature which allows you to execute code at compile time. This can be useful for generating code, performing static analysis, or optimizing performance and even for testing which is a really nice bonus and can be a small helper when it comes to memory safety.

Developer Ergonomics Matter and Developers are not Idiots

When developing software we want to be productive and efficient, most of all we want to be correct and produce good software, however we also want to enjoy the process of creation and not feel like we are fighting the tools we use. Developer ergonomics is a term that refers to how easy and comfortable it is to use a programming language or framework. It encompasses things like syntax, tooling, documentation, and community support. A language with good developer ergonomics can make it easier to write correct code, while a language with poor developer ergonomics can make it harder to do so. I'd say as it currently stands Rust has poor developer ergonomics but produces memory safe software, whereas Zig has good developer ergonomics and allows me to produce memory safe software with a bit of discipline.

I personally usually prefer languages where I do not have to succumb to too much ceremony and ritual to get things done, I want to be able to express my ideas in code without having to constantly think about the underlying mechanics of the language and yet I want to be responsible and produce good software. So with C and C++ this was a tiny bit harder as you basically had to learn some useful and practical memory management patterns and techniques, Zig comes with them baked in.

I feel like Zig really respects it's developers and treats them like adults, it gives you the tools and expects you to use them wisely. Rust on the other hand feels like it treats developers like children that need to be constantly supervised and guided, which can be frustrating and demotivating.

Developers are not idiots, sure even the smartest amongst us still produce memory safety issues or bugs in their software and it's silly to assume that with enough training and practice we can become perfect developers, but we can become better developers. We can learn from our mistakes and improve our skills, we can learn to write better code and produce better software.

It's not good to abstract that away to the compiler and assume that it will magically make us better developers, I don't personally think it will. In fact not to sound too cliche but I think that the journey to becoming a better developer is a series of mistakes and fixes, we learn from our mistakes and improve our skills. What does it say about a language that tries to abstract away the mistakes we make, does it really help us become better developers ?

Final Thoughts

Rust is amazing, if you’re building something massive, multithreaded, or long-lived, where compile-time guarantees actually save your life. The borrow checker, lifetimes, and ownership rules are a boon in large systems.

But for small, practical CLI tools? Rust can feel like overkill. That’s where Zig shines. Lightweight, fast, and straightforward, you get memory safety without constantly bending over backward for the compiler. You can allocate a list, track pointers, and mutate freely without extra wrappers, lifetimes, or contortions. Iterating feels natural, the code is easier to reason about, and you get stuff done faster.

Memory safety is important, but it’s just one piece of the puzzle. Predictable behavior, maintainable code, and robustness are just as critical, and that’s exactly why Zig often feels more practical for real-world CLI tools.

At the end of the day, it’s not about which language is “better.” It’s about what fits your workflow and the kinds of projects you build. For me, Zig hits the sweet spot: memory safe, low ceremony, and developer-friendly, perfect for small tools that actually get things done.

Are We Chasing Language Hype Over Solving Real Problems?

Dayvster 🌊 — Sat, 20 Sep 2025 09:33:46 +0000

Intro

As you may have heard or seen, there is a bit of controversy around Ubuntu adopting a rewritten version of GNU Core Utils in Rust. This has sparked a lot of debate in the tech community. This decision by Canonical got me thinking about this whole trend or push of rewriting existing software in Rust which seems to be happening a lot lately.

To put it bluntly I was confused by the need to replace GNU Core Utils with a new implementation as GNU Core Utils has been around since arguably the 90s and more realistically 2000s and it has been battle tested and proven to be reliable, efficient, effective and most importantly secure as it had basically never had any major security vulnerabilities in its entire existence. So why then would we deem it necessary to replace it with a new implementation in Rust? Why would anyone go through the trouble of rewriting something that already works perfectly fine and has been doing so for decades? When the end result at best is going to be a tool that does the same thing as the original and in the very best case scenario offer the same performance?

What bothers me even more is the bigger pattern this points to. Are we as developers more interested in chasing new languages and frameworks than actually solving real problems? I strongly subscribe to the idea that software development 60% problem solving and 40% creative exploration and innovation. But lately it feels like the balance is shifting more and more towards the latter. We seem to be more interested in trying out the latest and greatest languages and frameworks than actually solving real problems.

The Hype of New Languages and Shiny Object Syndrome

We've all been there in the past haven't we? Getting excited about a new programming language or framework that promises to solve all our problems and make our lives easier. It's easy to get caught up in the hype and want to try out the latest and greatest technology, but it's important to remember that just because something is new doesn't mean it's better. We need to be careful not to fall into the trap of "shiny object syndrome" where we chase after the latest trends without considering whether they actually solve our problems or improve our workflows. It's important to evaluate new technologies based on their merits and how they fit into our existing systems and workflows, rather than simply jumping on the bandwagon because everyone else is doing it.

Now for the important question:

Do I think the developers of coreutils-rs are doing this just because Rust is the new hotness?

Short and simple: No, no I do not. I believe they have good intentions and are likely trying to improve upon the existing implementation in some way. However, I do not agree with them that there is a need for a rewritten version of GNU Core Utils in Rust. I also do not agree that GNU Core Utils is inherently insecure or unsafe.

Why do we get Exited About New Languages?

It's also important to briefly touch upon the psychological aspect of why we get excited about new languages. New languages often come with new features, syntax, and paradigms that can be appealing to developers. They may also promise to solve problems that existing languages struggle with, such as performance, concurrency, or memory safety. Additionally, new languages can offer a fresh perspective on programming and can inspire creativity and innovation. Not to mention the community aspect, new usually means a changing of the guard, new people, new ideas, new ways of thinking about problems. All of these factors can contribute to the excitement and enthusiasm that developers feel when a new language is introduced.

This enthusiasm can sometimes lead to an almost zealous approach of wanting everything and anything to be written only in the new language by this new and fresh community of developers. This can lead to a situation where existing and well-established software is rewritten in the new language, even if there is no real need for it. This can be seen as a form of "language evangelism" where developers are trying to promote their favorite language by rewriting existing software in it.

The Case of GNU Core Utils

As I've briefly touched upon earlier, GNU Core Utils is a collection of basic file, shell and text manipulation utilities that are fundamental to the operation of Unix-like operating systems. These utilities include commands like ls, cp, mv, rm, cat, echo, and many others. They are essential for performing everyday tasks in the command line interface (CLI) and are used by system administrators, developers, and users alike.

Some of these can run hundreds of times per second, so performance is absolutely crucial. Even a small reduction in performance to a utility that is run by some OS critical daemon can have a significant impact on the overall performance of the system. GNU core utils has been optimized for this for about 30+ years at this point and is it really worth just tossing all of those lessons and optimizations out the window just to rewrite it in a new language?

I've also briefly touched upon that at best in the absolute best case scenario a rewritten version of GNU Core Utils in Rust would be able to match the performance of the original implementation. As we know GNU Core Utils are mostly written in C and some C++ mixed in sparingly. So far benchmarks have shown time and time again that at best with a lot of optimizations and tweaks Rust can only ever match the performance of C and in most cases it is actually slower. So the best case outcome of this rewrite is that we get a tool that does the same thing as the original and at best offers the same performance. So what is the actual benefit of this rewrite?

Where is the value, what is the actual problem that is being solved here?

When Hype Overshadows Real Problems

This is the crux of the issue, it's very very easy to get swept up in the excitement of a new language and want to use it for everything and anything under the sun. As developers we love novelty and communities with enthusiasm and fresh ideas. It's stimulating it's fun it feels like progress it feels like we are finally building something again instead of just rehashing and maintaining. We all know from personal experience that creating a new project is more fun and enjoyable than maintaining and existing one and this is a natural human tendency.

Now do I think this is one of the reasons the developers of coreutils-rs are doing this?

Yes, I do.

But in the end they are solving a problem that does not exist.

It's not just about Core Utils

Now with how often I've mentioned this specific example of GNU Core Utils you might think I want to single them out or have some sort of grudge or specific issue with this particular project. No, not really... I think this project is indicative of the larger issue we face in the tech community. It's very easy to get caught up in the excitement of new languages and frameworks and want to use them for everything and anything. This can lead to a situation where we are rewriting existing software in new languages without considering whether it actually solves any real problems or improves our workflows.

Problem Solving Should Be Our North Star

At the end of the day, software development is about solving real problems, not about chasing novelty, shiny new languages, or personal curiosity. Every line of code we write, every framework we adopt, every library we integrate should be justified by the problems it helps solve, not by the hype around it.

Yet increasingly, it feels like the industry is losing sight of this. We celebrate engineers for building in the “new hot language,” for rewriting tools, or for adopting the latest framework, even when the original solution worked perfectly fine. We reward novelty over necessity, excitement over impact.

This is not a phenomenon isolated to just core utils or systems programming, it happens in web development, mobile development, data science, and pretty much every other area of software development. We too often abandon tried and true solutions and ideas of new and exciting shiny ones without considering whether they actually solve any real problems or improve our workflows.

For example web development went full circle with React Server Components where we went from separation of concerns straight back to PHP style mixing of HTML and logic, server rendering and delivering interactive components to the client. Or the whole GraphQL craze where traditional REST APIs were abandoned en masse for a new and exciting way of doing things that promised to solve the dreaded problem of "over-fetching" and "under-fetching" of data. Yet in reality, it introduced a whole new set of problems and complexities that were not present in traditional REST APIs.

Or perhaps the whole microservices and microfrontend craze where a lot of projects were abandoned or rewritten to be split into smaller and smaller pieces,

Was it all bad? Should we always just stick to what works and only ever maintain legacy projects and systems? Heck no!

There is definitely a place for innovation and new ideas in software development. New languages, frameworks, and tools can bring fresh perspectives and approaches to problem-solving. However, it's important to evaluate these new technologies based on their merits and how they fit into our existing systems and workflows, rather than simply jumping on the bandwagon because everyone else is doing it.

We need to be more critical and thoughtful about the technologies we adopt and the projects we undertake. We need to ask ourselves whether a new language or framework actually solves a real problem or improves our workflows, or if we're just chasing novelty for its own sake.

A Final Thought

At the end of the day, it’s not about Rust, React, GraphQL, or the latest microservices fad. It’s about solving real problems. Every line of code, every framework, every rewrite should have a purpose beyond curiosity or hype.

We live in a culture that rewards novelty, celebrates “cool” tech, and often mistakes excitement for progress. But progress isn’t measured in how many new languages you touch, or how many shiny rewrites you ship, it’s measured in impact, in the problems you actually solve for users, teams, and systems.

So next time you feel the pull of the newest hot language, framework, or tool, pause. Ask yourself: “Am I solving a real problem here, or just chasing excitement?”

Because at the end of the day, engineering isn’t about what’s trendy, it’s about what works, what matters, and what actually makes a difference. And that, my friends, is the craft we should all be sharpening.