As a hobby Zig developer, it's a bummer to see a breaking change in something so fundamental, but I get that's what I accept when building on a pre-1.0 language.
I hope that the Zig team invests more into helping with migration than they have in the past. My experience for past breaking changes is that downstream developers got left in the cold without clear guidance about how to fix breaking changes.
In Zig 0.12.0 (released just a year ago), there were a lot of breaking changes to the build system that the release notes didn't explain at all. To see what I mean, look at the changes I had to make[0] in a Zig 0.11.0 project and then search the release notes[1] for guidance on those changes. Most of the breaking changes aren't even mentioned, much less explained how to migrate from 0.11.0 to 0.12.0.
>Some of you may die, but that is a sacrifice I am willing to make.
This arguably is why julia still has no real users and python, c++, and fortran still rule in hpc, despite hypsters doing the hyping.
At some point people just want their code to work so they go back to something that just works and won't break in a few years.
blippage · 4h ago
I tried Zig some time ago to use with microcontrollers. It has a generator for the pins, which was nice. But subsequent versions broke as Zig changed syntax. So I started going down the rabbit-hole (it needed a newer version of llvm, for example) until I eventually decided that the game wasn't worth the candle.
The fact that another breaking change has been introduced confirms my suspicion that Zig is not ready for primetime.
My conclusion is to just use C. For low-level programming it's very hard to improve on C. There is not likely to be any killer feature that some other contender will allow you to write the same code in a fifth of the lines nor make the code any more understandable.
Yes, C may have its quirky behaviour that people gnash their teeth over. But ultimately, it's not that bad.
If you want to use a better C, use C++. C++ is perfectly fine for using with microcontrollers, for example. Now get back to work!
scrubs · 23m ago
Well, that's a sentiment I don't quite agree with. It willfully ignores industry experience with c/c++ whence zig, rust, D, and others.
If your micro controller is say <5000 lines maybe ... but an OS or a mellanox verbs or dpdk API won't fall so easily to such surface level thinking.
Maybe zig could help itself by providing through llvm what Google sometimes does for large api breaking changes ... have llvm tool that searches out old api invocation update to new so upgrading is faster, more operationally effective.
Google's tools do this and give the dev a source code pr candidate. That's how they can change zillions of calls with confidence.
steeve · 2h ago
It absolutely is and we (ZML) are using it with great success. That said, Andrew said he would absolutely would break compat if it meant things go in the right direction.
Yes, it can be painful sometimes, yes I do not always agree with his choices, but it has never been a blocker nor a significant time sink.
And in the end, things do improve significantly.
In this case, I think the new IO stuff is incredible.
xeonmc · 1h ago
It also helps job prospects of Zig programmers within organizations that have already adopted Zig -- more breakage, more job security.
ulbu · 1h ago
advances the purposes of cynics as well, so big bonus.
eddythompson80 · 3h ago
> The fact that another breaking change has been introduced confirms my suspicion that Zig is not ready for primetime.
Huh, it was the 0.14 version number for me.
dtech · 3h ago
0.x doesn't say as much as it used to 20 years ago, many fine projects keep it for way too long.
eddythompson80 · 3h ago
Zig has a pretty well documented 1.0 goals. It was the first thing I heard about zig from Andrew about. https://youtu.be/5eL_LcxwwHg
arp242 · 2h ago
Yes, that was the point. To understand what that "0.14" means, we need to know those "well documented 1.0 goals" and some hour long YouTube video. That is, merely the "0.14 version number" without context is not enough, like your previous comment said.
eddythompson80 · 2h ago
You look at the version, the milestones https://github.com/ziglang/zig/milestones, and it makes sense. The YouTube video is just more proof. Picking up a 0.14 software without looking the most basic thing about it like “oh, what kind of 0.14 is this” then complaining that “it’s not ready for prime time” is odd behavior
flohofwoe · 1h ago
Well, that's why Zig is 0.x and not 1.x. I'm fine even with large scale breakage if the direction is right (and looking at the mess that C++ has become for the sake of backward compatibility, IMHO breaking changes are also the better option after 1.x, as long as there's features to help manage the required changes).
Also, "Zig the language" is currently better designed than "Zig the stdlib", so breaking changes will actually be needed in the future at least in the stdlib because getting it right the first time is very unlikely, and I don't like to be stuck with bad initial design decisions which then can't be fixed for decades (again, as a perfect example of how not to do it, see C++)
vlovich123 · 3h ago
I haven’t done embedded stuff in Rust, but the nostd crates and automatically generated libraries from manufacturer SVDs seemed neat. The ability to trivially pull in already written functionality would also seem fantastic.
sgt · 4h ago
But at some point it'll be ready. Might it be worth it then?
I also have to disagree with C++ for micro controllers / bare metal programming.
You don't get the standard library so you're missing out on most features that make C++ worthwhile over C.
Sure you get namespaces, constexpr and templates but without any standard types you'll have to build a lot on your own just to start out with.
I recently switched to Rust for a bare metal project and while its not perfect I get a lot more "high level" features than with C or C++.
TuxSH · 2h ago
> You don't get the standard library
Why is that? Sure, allocating containers and other exception-throwing facilities are a no-go but the stdlib still contains a lot of useful and usable stuff like <type_traits>, <utility>, <source_location>, <bit>, <optional>, <coroutine> [1] and so on
[1] yes they allocate, but operator new can easily be overridden for the promise class and can get the coro function arguments forwarded to it. For example if coro function takes a "Foo &foo", you can have operator new return foo.m_Buffer (and -fno-exceptions gets rid of unwinding code gen)
tialaramex · 1h ago
In the C and C++ languages there's a thing called a "freestanding" implementation. This is roughly analogous to Rust's nostd.
In C the freestanding environment doesn't provide any concrete features, you don't get any functions at all, you can get a bunch of useful constants such as the value of Pi or the maximum value that will fit in an unsigned integer, some typedefs, that's about it. Concrete stuff from the "C standard library" is not available, for example it does not provide any sort of in-place sort algorithm, or a way to compare whether two things are the same (if they fit in a primitive you can use the equality operator)
In C++ there are concrete functions provided by the language standard in freestanding mode. These, together with definitions for types etc. form the freestanding version of the "standard library" in C++. There's a long period where this was basically untended, it wasn't removed but it also wasn't tracking new features or feedback. In the last few C++ versions that improved, but even if you have a new enough compiler and it's fully compliant (most are not) there's still not always a rhyme or reason to what is or is not available.
In Rust it's really easy. You always have core, if you've got a heap allocator of some sort you can have alloc, and if there's a whole operating system it provides std.
In most cases a whole type lives entirely in one of those modules, Duration for example lives in core. Maybe your $5 device has no idea which year this is, let alone day but it does definitely know 60 seconds is a minute.
But in some cases modules extend a type. For example arrays exist in core of course - an array of sixty Doodads where Doodads claim to be Totally Ordered, can just be unstably sorted, that works. But, what if we want a stable sort, so that if two equal Doodads were arranged A, B they are not reversed B, A ? Well Rust's core module doesn't provide a stable sort, the stable sort provided uses an allocation and so the entire function you need just doesn't exist unless you've got allocators.
gpderetta · 10m ago
What the standard says about freestanding is all well and good. But what do actual embedded c++ compilers actually ship?
Also embedded covers a very wide range of computers.
juliangmp · 2h ago
That's the most frustrating part, a lot of the std library would work on a bare metal system (and would be rather useful), but getting those parts into your project and avoiding the ones that will give you compiler errors in form of esoteric poems is a nightmare.
Vendors at this point seem to give their implementation of some of the std library components, but the one's I've seen were lacking in terms of features.
DanielHB · 2h ago
This is a problem with WASM as well, use a certain innocent function from the C++ std lib and suddenly your WASM binary grows by 10mb.
vlovich123 · 3h ago
Doesn’t Rust nostd give up a comparable part that C++ would give up? It’s typically all the memory allocations that inhibit the use of data structures.
juliangmp · 2h ago
Yeah you don't get its std library, but Rust makes a distinction between core and std, and core is available.
Doesn't sound like a lot but you get your standard types like Result and Option, you get slices since they're part of the language or if you need allocation you can define the global allocator in core::alloc.
This distinction makes it really comfortable to use.
Is that versioning site supposed to be some kind of joke? I can't really figure out if they are joking or serious - the tone comes off as joking, but it could be read as serious too.
dtech · 3h ago
I guess you're being Poe's lawwed but it's definitely a joke
self_awareness · 3h ago
The point of the language stability is spon on, but it's actually very easy to improve on C, not in terms of performance or readability, but rather safety and the ability to encode more constraints in a compact form than C would ever allow. Sometimes it's not about less lines, but the same amount of lines that encode a lot more stuff than these lines in C.
zwnow · 4h ago
And this is exactly why you do not use shiny new languages for your projects. Hope tigerbeetle won't have too much trouble with this
jorangreef · 3h ago
This is exactly why we chose Zig.
Andrew’s design decisions in the language have always been impeccable. I’ve never seen him put a foot wrong and would have made the same change myself.
This is also not new to us, Andrew spoke about this at Systems Distributed ‘25.
Also, TigerBeetle has and owns its own IO stack in any event, and we’ve always been careful to use stable language features.
But regardless, it’s in our nature to “do the right thing”, even if that means a bit of change. We call this “Edge” and explicitly hire for people who have the same characteristic, the craftspeople who know how to spot great technical quality, regardless of how young (or old!) a project may be.
Finally, I’ve been in Zig since 2018. I wouldn’t exactly call it “shiny new”. Zig already has the highest quality toolchain and std lib of anything I would use.
tialaramex · 3h ago
> Andrew’s design decisions in the language have always been impeccable. I’ve never seen him put a foot wrong and would have made the same change myself.
Interesting, who designed the old Zig IO stack which alas Andrew needed to replace?
eddythompson80 · 3h ago
A less experienced Andrew
BrouteMinou · 2h ago
I've built a bridge 20 years ago. It was great, people could finally go from one side of the river to the other.
Everyday, more and more people started using that bridge.
In 2025, I've rebuilt the bridge twice as big to accommodate the demand of a growing community.
It's great and the people love it!
eviks · 3h ago
Indeed, but to be fair, the old stack was done with a hand, not a foot!
jorangreef · 2h ago
I think what you're not appreciating is how this design is a huge improvement over the status quo, not only in Zig, but also the streaming interfaces in most languages.
Wait till the SD25 talk on this comes out, to first understand the rationale a bit better!
robertlagrant · 2h ago
> I think what you're not appreciating is how this design is a huge improvement
The point was that if he did the old design, which needed improving enough to justify breaking the language backwards compatibility, then why say his decisions are impeccable? Pobody's nerfect.
jorangreef · 2h ago
Yes, and my point (in response) was that Zig's status quo was no different from other languages, but now is better. (There's some humor in the issue's title “Writergate” here!)
Again, we use Zig, and this change is welcome for us.
We also like that Zig is able to break backwards compatibility, and are fully signed up for that.
The crucial thing for TigerBeetle is that Zig as language will make the right calls looking to the next few decades, rather than ossify for fear of people who don't use it.
DanielHB · 2h ago
> Zig already has the highest quality toolchain and std lib of anything I would use.
My couple of days experience with Zig was very lackluster with the std lib, not that it is bad, but feels like it is lacking a lot of bare essentials. To be expected for a new pre-1.0 language of course.
flohofwoe · 1h ago
Depends on which language you're coming from. Compared to C or even C++, the Zig stdlib has already many more things to offer. Compared to Python it's quite bare bones (but then, everything is).
zwnow · 3h ago
Good to know, also thanks for the detailed reply! Glad you are fully aware of these nuances, but it also doesn't surprise me considering your amazing presentation of Tigerbeetle! Much success in the future.
jorangreef · 2h ago
Thanks zwnow, appreciate your kind words, and my pleasure!
I think you'll enjoy Andrew's talk on this too when it comes out in the next few weeks.
The velocity of Zig has been valuable for us. Being able to put things like io_uring or @prefetch in the std lib or language, and having them merged quickly. Zig has been so solid, even with all the fuzzing we do. It's really held up, and upgrades across versions have not been much work, only a pleasure.
hmry · 4h ago
Zig is the only language I've used where every library specifies the one (and only) compiler version it works on in their GitHub readme.
flohofwoe · 1h ago
How many pre-release languages are you typically using though?
kunley · 3h ago
Experienced quite the contrary, some time ago at least..
Which is a pity because really liked the language, but the discovering what works with what, oh dear
ozgrakkurt · 4h ago
TigerBeetle uses io_uring afaik so they don’t use these io interfaces at all.
Also found that these interfaces only cause problems for performance and flexibility in rust so didn’t even look at them in zig.
eviks · 4h ago
The risk isn't unique to shiny new languages
Hamuko · 4h ago
Are people deploying production code in a language that is still in its 0.x version?
ozgrakkurt · 4h ago
A lot of people were using tokio in prod when it was 0.1 and didn’t get upset afaik.
Rust didn’t even have async await at that time
bogdan · 2h ago
Some prod are more prod than the others.
Ygg2 · 1h ago
> A lot of people were using tokio in prod when it was 0.1 and didn’t get upset afaik.
Citation needed. A lot of people wanted Rust to stabilize. Hence why they huried to Rust 1.0.
cenamus · 4h ago
I mean, what's the difference to the python 2/3 debacle? People were writing/extending in python 2 long after it was declared obsolete
Hamuko · 4h ago
Not having breaking changes every N months?
flohofwoe · 1h ago
Each new minor Python 3.x version has plenty of deprecations followed by removals in the stdlib though.
mirashii · 4h ago
It's not about sticking around on an old version, it's about ever being able to catch up, and what the rest of the ecosystem is going to do. Python did this major version bump that broke a lot of the ecosystem, and it went so poorly that they've effectively promised never to do it again and completely excised any thought of ever having a major version bump again, and other languages and communities now point to it regularly as a debacle to be avoided.
When you break things regularly, you're forcing a choice on every individual package in the ecosystem: move forward, and leave the old users behind, or stay behind, and risk that the rest of the ecosystem moves forward without you. Now you've got a whole ecosystem in a prisoner's dilemma. For an individual, maybe you can make a choice and dig in and make your way along without too much trouble. But the ecosystem as a whole can't, the ecosystem fractures, and if it doesn't converge on the latest version, it slowly withers and dies.
zwnow · 4h ago
I dont but there are companies who trust the language (which is a good thing but also short sighted)
kristoff_it · 3h ago
For context this was presented, alongside other things, in the Zig Roadmap 2026 stream.
This is why it's good to have automated tooling that can do semantic changes on your language and standard library use. Go has `go fix` even if it was only used in pre-1.0 days AFAIK. It is never lost because this type of tooling can be used as the foundation for linters, refactoring tools, etc. Is there such a solution in Zig?
flohofwoe · 1h ago
zig fmt has some auto-fixes for upgrading source code to new Zig versions, AFAIK it's only for language changes, not stdlib changes though.
Aissen · 5m ago
Nice, I wonder if adapting it for this change would make sense?
GolDDranks · 2h ago
I have written very little Zig and a lot of Rust, but I love both languages. However, Zig having breaking changes has made me wary of not starting anything serious it with – yet. I'm still happy that these changes happen, because I'm willing to wait for a stable version. Meanwhile, I enjoy myself some Rust, and probably continue doing so.
brabel · 5h ago
I like Zig but it seems to just keep redesigning itself, while other languages like Odin “shipped” long ago and don’t seem to need to look back. Is Zig suffering from perfectionism syndrome where things are never good enough??
audunw · 4h ago
This is a standard library change, not a syntax change
I think the main big thing that’s left for 1.0 is to resurrect async/await.. and that’s a huge thing because arguably very few if any language has gotten that truly right.
As the PR description mentions: “This is part of a series of changes leading up to "I/O as an Interface" and Async/Await Resurrection.”
So this work is partially related to getting async/await right. And getting IO right is a very important part of that.
I think it’s a good idea for Zig to try to avoid a Python 3 situation after they reach 1.0. The project seems fairly focused to me, but they’re trying to solve some difficult problems. And they spend more time working on the compiler and compiler infrastructure than other languages, which is also good. Working on their own backend is actually critical for the language itself, because part of what’s holding Zig back from doing async right is limitations and flaws in LLVM
travisgriggs · 3h ago
> I think the main big thing that’s left for 1.0 is to resurrect async/await.. and that’s a huge thing because arguably very few if any language has gotten that truly right.
Interesting. I like Zig. I dabble periodically. I’m hoping that maturity and our next generation ag tech device in a few years might intersect.
Throwing another colored function debacle in a language, replete with yet another round of the familiar but defined slightly differently keywords, would be a big turn off for me. I don’t even know if Grand Central Dispatch counts, but it—and of course Elixir/Erlang—are the only two “on beyond closures/callbacks” asynch system I’ve found worked well.
messe · 3h ago
As far as I know, Zig still wants their implementation of async to avoid function colouring.
stratts · 1h ago
My understanding is that the current plans are to implement async in userspace, as part of a broader IO overhaul.
This would involve removing async/await as keywords from the language.
dosshell · 4h ago
>> because part of what’s holding Zig back from doing async right is limitations and flaws in LLVM
this was interesting! Do you have a link or something to be able to read about it?
audunw · 4h ago
Much of the discussion is buried in the various GitHub issues related to async. I found something of a summary in this Reddit comment
Sorry, I think this comparison is just unfair. Odin might have "shipped" but are there are any projects with significant usage built on it? I can count at least 3 with Zig - Ghostty, Tigerbeetle, and Bun.
Programming languages which do get used are always in flux, for good reason - python is still undergoing major changes (free-threading, immutability, and others), and I'm grateful for it.
LukaD · 4h ago
All the JangaFX products (such as EmberGen) are written in Odin.
thelastbender12 · 4h ago
Thank you, my bad - I wasn't aware.
I still think what drives languages to continuously make changes is the focus on developer UX, or at least the intent to make it better. So, PLs with more developers will always keep evolving.
dismalaf · 4h ago
> Odin might have "shipped" but are there are any projects with significant usage built on it?
JangaFX stuff is written in Odin and has some pretty big users.
I'd say it is taking some serious design decision for like the 30 years to come, so I am happy it breaks things now.
I wish it moved to snake_case for functions, this is a cosmetic detail but it drives me crazy.
pjmlp · 4h ago
If I look to how I was programming in 1986, and how I am programming now, it is too much hope to have such a design goal, especially since most likely there is little Zig has to add to quantum and AI based systems.
lionkor · 4h ago
This feels out of touch with the actual industry today.
pjmlp · 3h ago
Out of touch is assuming that a programming language with zero touch points with AI tooling is going to be relevant in a AI driven industry.
lionkor · 1h ago
What is "AI tooling"?
pjmlp · 17m ago
Ask Chat GPT, Claude or Gemini.
cornstalks · 5h ago
I’m glad they are taking their time. They’ve made solid improvements and I don’t think get the sense that they’re paralyzed with perfectionism.
They’re not rushing, that’s for sure. But I’ve never felt worried about 1.0 never happening in an unending pursuit of unrealistic impossible ideals.
vendiddy · 4h ago
They've been pretty explicit about their goals in not settling for a local optimum in the language and taking their time.
It seems like folks expect stability pre 1.0.
pjmlp · 4h ago
Looks like it, while at the same time still lacks any killer application that would make learning Zig a requirement, regardless of one's opinion on the language, like it already happened with many others now in mainstream.
So where is Zig's OS, browser, docker, engine, security, whatever XYZ, that would make having Zig on the toolbox a requirement?
I don't see Bun nor Tiger Beetle being that app.
dgb23 · 2h ago
Not a killer app, but I think one thing you might consider is zig build.
pjmlp · 13m ago
Not a seller to me.
lionkor · 4h ago
The killer application case is slow adoption inside ancient C and C++ codebases. That's the angle.
pjmlp · 3h ago
It hardly brings anything new to the table in such cases, given its approach to safety.
Most of it you can already get in C and C++, by using the tools that have in the market for the last 30 years.
lionkor · 1h ago
It brings a lot of nice features, the potential for a healthier ecosystem, a unified build system, explicit allocators, explicit casts, and so on.
pjmlp · 14m ago
Ecosystems sell languages, not the other way around.
lewdwig · 3h ago
And yet C/C++ developers have mostly spent the last 30 years not using those tools which is why safer successors to C and C++ appeared.
pjmlp · 15m ago
Zig is as safe as Modula-2 or Object Pascal, not the turning point of something like Swift or Rust.
detaro · 3h ago
I think pjmlps point is that Zig is not adding enough to be one of those safer successors.
silisili · 5h ago
That's kinda my experience with watching Zig. It went from 'look how simple this is' to 'look at this new feature syntax' long ago.
People used to compare it as simpler than Rust. I don't agree that it's simple anymore at all.
None of this is meant to be badmouthing or insulting. I'm a polyglot but love simple languages and syntaxes, so I tend to overly notice such things.
Laremere · 4h ago
The computer is a machine, and modern ones are complicated. When I am programming, I want to precisely control that machine. For me, simplicity is measured in how complicated it is to get the machine to do what I want it to do. So, eg, having several different operators for adding two integers sounds complicated. However there is simplicity in not having to reach far to actually get the correct behavior, and there is some simplicity in the process of being forced to make that choice as it irons about what behavior you actually want.
silisili · 4h ago
I think that's long been the argument of simplicity. 'Simple to remember' vs 'simple to perform.'
I tend to fall into the former camp. Something like BF would be the ultimate simple language, even if not particularly useful.
lewdwig · 3h ago
Structured concurrency is a notoriously hard problem. This is part of Zig’s 4th attempt to get it right.
raincole · 57m ago
Rust will be (already became?) as complex as C++, if not more. Zig will be as complex as early rust. It's like a force of nature.
drtgh · 4h ago
By the title I thought that they were going to implement this,
At my first job, the senior guy on my team used to say:
"Software is just like lasagna. It has many layers, and it tastes best after you let it sit for a while".
I still follow this principle years down the line and avoid introducing shiny new things on my projects.
WhereIsTheTruth · 2h ago
well, in that case, the lasagna is still being cooked, until served (1.0), why question the chef?
let him cook
ksynwa · 5h ago
Is Writergate a technical term or a reference to Watergate?
n42 · 5h ago
in a sense it's a reference to Allocgate (a previous big breaking change to allocators in Zig), which was itself a reference to Watergate
kzrdude · 2h ago
by now it's a well worn/used trope to make -gate names for any scandal. But the distance in time (and culture) to the original Watergate scandal is growing, so it seems less impactful now.
Whelp, I ain't ever touching Zig if this is how it is developed.
thiht · 2h ago
Programming language in version 0.14 has breaking changes, UNACCEPTABLE
rcastellotti · 2h ago
thanks for the info, do keep us updated please
ladyanita22 · 2h ago
Be as sarcastic as you want. This is a feeling many developers probably share.
3836293648 · 2h ago
Then those developers won't ever use anything ever. Why would breaking changes in an explicitly unstable development version exclude it from use for all time?
If you want stability, stick to stuff that has stability guarantees, but at the very least let them make breaking changes during development.
I hope that the Zig team invests more into helping with migration than they have in the past. My experience for past breaking changes is that downstream developers got left in the cold without clear guidance about how to fix breaking changes.
In Zig 0.12.0 (released just a year ago), there were a lot of breaking changes to the build system that the release notes didn't explain at all. To see what I mean, look at the changes I had to make[0] in a Zig 0.11.0 project and then search the release notes[1] for guidance on those changes. Most of the breaking changes aren't even mentioned, much less explained how to migrate from 0.11.0 to 0.12.0.
>Some of you may die, but that is a sacrifice I am willing to make.
>-Lord Farquaad
[0] https://github.com/mtlynch/zenith/pull/90/files#diff-f87bb35...
[1] https://ziglang.org/download/0.12.0/release-notes.html
At some point people just want their code to work so they go back to something that just works and won't break in a few years.
The fact that another breaking change has been introduced confirms my suspicion that Zig is not ready for primetime.
My conclusion is to just use C. For low-level programming it's very hard to improve on C. There is not likely to be any killer feature that some other contender will allow you to write the same code in a fifth of the lines nor make the code any more understandable.
Yes, C may have its quirky behaviour that people gnash their teeth over. But ultimately, it's not that bad.
If you want to use a better C, use C++. C++ is perfectly fine for using with microcontrollers, for example. Now get back to work!
If your micro controller is say <5000 lines maybe ... but an OS or a mellanox verbs or dpdk API won't fall so easily to such surface level thinking.
Maybe zig could help itself by providing through llvm what Google sometimes does for large api breaking changes ... have llvm tool that searches out old api invocation update to new so upgrading is faster, more operationally effective.
Google's tools do this and give the dev a source code pr candidate. That's how they can change zillions of calls with confidence.
And in the end, things do improve significantly.
In this case, I think the new IO stuff is incredible.
Huh, it was the 0.14 version number for me.
Also, "Zig the language" is currently better designed than "Zig the stdlib", so breaking changes will actually be needed in the future at least in the stdlib because getting it right the first time is very unlikely, and I don't like to be stuck with bad initial design decisions which then can't be fixed for decades (again, as a perfect example of how not to do it, see C++)
I also have to disagree with C++ for micro controllers / bare metal programming. You don't get the standard library so you're missing out on most features that make C++ worthwhile over C. Sure you get namespaces, constexpr and templates but without any standard types you'll have to build a lot on your own just to start out with.
I recently switched to Rust for a bare metal project and while its not perfect I get a lot more "high level" features than with C or C++.
Why is that? Sure, allocating containers and other exception-throwing facilities are a no-go but the stdlib still contains a lot of useful and usable stuff like <type_traits>, <utility>, <source_location>, <bit>, <optional>, <coroutine> [1] and so on
[1] yes they allocate, but operator new can easily be overridden for the promise class and can get the coro function arguments forwarded to it. For example if coro function takes a "Foo &foo", you can have operator new return foo.m_Buffer (and -fno-exceptions gets rid of unwinding code gen)
In C the freestanding environment doesn't provide any concrete features, you don't get any functions at all, you can get a bunch of useful constants such as the value of Pi or the maximum value that will fit in an unsigned integer, some typedefs, that's about it. Concrete stuff from the "C standard library" is not available, for example it does not provide any sort of in-place sort algorithm, or a way to compare whether two things are the same (if they fit in a primitive you can use the equality operator)
In C++ there are concrete functions provided by the language standard in freestanding mode. These, together with definitions for types etc. form the freestanding version of the "standard library" in C++. There's a long period where this was basically untended, it wasn't removed but it also wasn't tracking new features or feedback. In the last few C++ versions that improved, but even if you have a new enough compiler and it's fully compliant (most are not) there's still not always a rhyme or reason to what is or is not available.
In Rust it's really easy. You always have core, if you've got a heap allocator of some sort you can have alloc, and if there's a whole operating system it provides std.
In most cases a whole type lives entirely in one of those modules, Duration for example lives in core. Maybe your $5 device has no idea which year this is, let alone day but it does definitely know 60 seconds is a minute.
But in some cases modules extend a type. For example arrays exist in core of course - an array of sixty Doodads where Doodads claim to be Totally Ordered, can just be unstably sorted, that works. But, what if we want a stable sort, so that if two equal Doodads were arranged A, B they are not reversed B, A ? Well Rust's core module doesn't provide a stable sort, the stable sort provided uses an allocation and so the entire function you need just doesn't exist unless you've got allocators.
Also embedded covers a very wide range of computers.
Vendors at this point seem to give their implementation of some of the std library components, but the one's I've seen were lacking in terms of features.
This distinction makes it really comfortable to use.
Though one caveat about no_std is that you'll need some support library like https://docs.rs/cortex-m-rt/latest/cortex_m_rt/
https://0ver.org/
Andrew’s design decisions in the language have always been impeccable. I’ve never seen him put a foot wrong and would have made the same change myself.
This is also not new to us, Andrew spoke about this at Systems Distributed ‘25.
Also, TigerBeetle has and owns its own IO stack in any event, and we’ve always been careful to use stable language features.
But regardless, it’s in our nature to “do the right thing”, even if that means a bit of change. We call this “Edge” and explicitly hire for people who have the same characteristic, the craftspeople who know how to spot great technical quality, regardless of how young (or old!) a project may be.
Finally, I’ve been in Zig since 2018. I wouldn’t exactly call it “shiny new”. Zig already has the highest quality toolchain and std lib of anything I would use.
Interesting, who designed the old Zig IO stack which alas Andrew needed to replace?
Everyday, more and more people started using that bridge.
In 2025, I've rebuilt the bridge twice as big to accommodate the demand of a growing community.
It's great and the people love it!
Wait till the SD25 talk on this comes out, to first understand the rationale a bit better!
The point was that if he did the old design, which needed improving enough to justify breaking the language backwards compatibility, then why say his decisions are impeccable? Pobody's nerfect.
Again, we use Zig, and this change is welcome for us.
We also like that Zig is able to break backwards compatibility, and are fully signed up for that.
The crucial thing for TigerBeetle is that Zig as language will make the right calls looking to the next few decades, rather than ossify for fear of people who don't use it.
My couple of days experience with Zig was very lackluster with the std lib, not that it is bad, but feels like it is lacking a lot of bare essentials. To be expected for a new pre-1.0 language of course.
I think you'll enjoy Andrew's talk on this too when it comes out in the next few weeks.
The velocity of Zig has been valuable for us. Being able to put things like io_uring or @prefetch in the std lib or language, and having them merged quickly. Zig has been so solid, even with all the fuzzing we do. It's really held up, and upgrades across versions have not been much work, only a pleasure.
Which is a pity because really liked the language, but the discovering what works with what, oh dear
Also found that these interfaces only cause problems for performance and flexibility in rust so didn’t even look at them in zig.
Rust didn’t even have async await at that time
Citation needed. A lot of people wanted Rust to stabilize. Hence why they huried to Rust 1.0.
When you break things regularly, you're forcing a choice on every individual package in the ecosystem: move forward, and leave the old users behind, or stay behind, and risk that the rest of the ecosystem moves forward without you. Now you've got a whole ecosystem in a prisoner's dilemma. For an individual, maybe you can make a choice and dig in and make your way along without too much trouble. But the ecosystem as a whole can't, the ecosystem fractures, and if it doesn't converge on the latest version, it slowly withers and dies.
VOD: https://youtu.be/x3hOiOcbgeA
I think the main big thing that’s left for 1.0 is to resurrect async/await.. and that’s a huge thing because arguably very few if any language has gotten that truly right.
As the PR description mentions: “This is part of a series of changes leading up to "I/O as an Interface" and Async/Await Resurrection.”
So this work is partially related to getting async/await right. And getting IO right is a very important part of that.
I think it’s a good idea for Zig to try to avoid a Python 3 situation after they reach 1.0. The project seems fairly focused to me, but they’re trying to solve some difficult problems. And they spend more time working on the compiler and compiler infrastructure than other languages, which is also good. Working on their own backend is actually critical for the language itself, because part of what’s holding Zig back from doing async right is limitations and flaws in LLVM
Interesting. I like Zig. I dabble periodically. I’m hoping that maturity and our next generation ag tech device in a few years might intersect.
Throwing another colored function debacle in a language, replete with yet another round of the familiar but defined slightly differently keywords, would be a big turn off for me. I don’t even know if Grand Central Dispatch counts, but it—and of course Elixir/Erlang—are the only two “on beyond closures/callbacks” asynch system I’ve found worked well.
This would involve removing async/await as keywords from the language.
this was interesting! Do you have a link or something to be able to read about it?
https://www.reddit.com/r/Zig/comments/1d66gtp/comment/l6umbt...
Programming languages which do get used are always in flux, for good reason - python is still undergoing major changes (free-threading, immutability, and others), and I'm grateful for it.
I still think what drives languages to continuously make changes is the focus on developer UX, or at least the intent to make it better. So, PLs with more developers will always keep evolving.
JangaFX stuff is written in Odin and has some pretty big users.
https://jangafx.com/ https://odin-lang.org/showcase/
I wish it moved to snake_case for functions, this is a cosmetic detail but it drives me crazy.
They’re not rushing, that’s for sure. But I’ve never felt worried about 1.0 never happening in an unending pursuit of unrealistic impossible ideals.
It seems like folks expect stability pre 1.0.
So where is Zig's OS, browser, docker, engine, security, whatever XYZ, that would make having Zig on the toolbox a requirement?
I don't see Bun nor Tiger Beetle being that app.
Most of it you can already get in C and C++, by using the tools that have in the market for the last 30 years.
People used to compare it as simpler than Rust. I don't agree that it's simple anymore at all.
None of this is meant to be badmouthing or insulting. I'm a polyglot but love simple languages and syntaxes, so I tend to overly notice such things.
I tend to fall into the former camp. Something like BF would be the ultimate simple language, even if not particularly useful.
https://github.com/ziglang/zig/issues/5973
"Software is just like lasagna. It has many layers, and it tastes best after you let it sit for a while".
I still follow this principle years down the line and avoid introducing shiny new things on my projects.
let him cook
No comments yet
If you want stability, stick to stuff that has stability guarantees, but at the very least let them make breaking changes during development.