The area that we maybe ignore

Zig originated created for desktop applications development(genesis daw) and found practical application in the web backend(tigerbeetle, bun). Game engines and embedded systems also have applications(mach, microzig), but progress has been slow. There is a wide application area that we will ignore, and that is firmware development.
UEFI/MinPlatform, coreboot, u-boot, TEE, there are very popular firmwares. Every computer has a uefi firmware, every chromebook and many cloud servers have coreboot inside, most linux SBCs have a u-boot, and every mobile phone has a TEE firmware. They are quite widely used and are written in C.
Zig is good for low-level software development, and very compatible to C. Zig can be a good alternative to C in firmware development, I think this is an area where zig can do a lot.


I’ve written some firmware for arduino in Zig and I can attest that the code is much more readable than other languages I’ve come across. There’s a thread dedicated to embedded/microprocessor code on the Zig discord if you haven’t already checked it out (granted, this isn’t exactly the topic you’re referring to here).

It doesn’t surprise me that this is the case, however. Application and backend code is a big part of software development. It’s also worth noting that Zig has not reached 1.0 yet and there’s plans for massive (and in the words of the Zig core team, apocalyptic) changes that will be coming down the pipeline as more milestones are achieved towards the 1.0 release.

Take for example C++… it may be frustrating that there are so many versions of it that are release date dependent but that essentially means that C++11/14/17/20 are foundationally complete and have their own compilers/maintainers. This is helpful from the view point of a company because they won’t have to change their entire codebase next week because a new fundamental change that radically alters the language rules has been introduced.

This is just my take, but much of what we see right now is still a proof of concept. There’s whole categories of errors still being introduced (the newest one being non mutated var’s being flagged).

I say all of this to point out that Zig really hasn’t seen it’s full potential in general as it’s still highly experimental at the moment. I imagine there will be a bigger push towards what you’re referring to (and much more) as the language develops further.

Wow, where do the ordinary programmer can get information about these changes, in order to brace itself for the shock?

The one I am referring to is audit the standard library API and implementations · Issue #1629 · ziglang/zig · GitHub

The comment I’m referencing was made in relation to that milestone - keep in mind, the Zig core team has a good sense of humor and do care about their community and support - there’s no milestone for throwing everyone under the bus lol.

To be clear, I am 100% in support of this milestone. They’ve made it clear for a while that large parts of the standard library are going to get moved around for quite some time.

Return location semantics is still finding it’s place but it’s settling in nicely after all this time. Even in this last year, Zig has changed a lot - RLS removed formerly required explicit type arguments from builtins and changed a lot of things in the process. Again, the compiler is now tracking mutations and flagging uses of var as invalid if you don’t mutate them. There’s certainly going to be more changes and the reintroduction of async will be another big shift (it was pulled once before - I believe when the switch over to the self hosted compiler happened).

They’re very public about the roadmap and what parts of it they’re aware of. Browse through the milestones: Milestones - ziglang/zig · GitHub


Zig was created to be a modern systems programming language. By definition, it should be good for any performance critical or bare-metal application. I haven’t heard anywhere that it was created particularly for desktop application development.

Firmware support is great! The language was designed with firmware in mind. Like C, you can use all of the language features because there is no required runtime. Unlike C, you can go right ahead and @import(“std”) and use as much of it as your target allows. Bonus points if you have an allocator.

For same reasons as firmware, it’s great for kernels, bootloaders, and UEFI. I don’t know about you, but I’d rather set my target to x86_64-uefi and utilize the (albeit unfinished) Zig standard library than try and figure out how to setup EDKII on Windows.