I maintain a library to interface zig with elixir and the breaking changes have not been a big deal. As a part of the library I have maintain a zig parser (the official parser in the langref is not up to date) and I scan the entire zig codebase against my parser to make sure it doesn't trip up on anything. Also I can't use zig fmt to keep up because some of the code is templated and embedded in Elixir. The last two semver minor updates, the net total amount of changes I have had to do to keep up with the language took me maybe an hour? Also subjectively, I feel like the breaking changes that affect me have been fewer and easier to deal with since the early days. The bulk of the delay in updating the library was chipping away at things that i had put off since the last update (also i don't use the library in $DAYJOB since I "quit tech", though I do vibecode solutions for myself).
Point being, I feel like a lot of the gripes about zig changing here and there are really by folks who aren't really daily users, just people who see a !!breaking change!! announcement and pile on.
Though, I do sympathize with newcomers because the memory of the internet is pinned to various older versions with lots of demo code that 'just doesn't work' and of course that means LLMs too, in the long run. Hopefully zig doesn't get stuck past the global knowledge/popularity LLM-cycle cutoff. I don't think it will.
The problem for newcomers is something I faced when trying to use Zig, particularly for the build system. I heard a lot about how much nicer the build system is in Zig compared to other tools. However, as someone unfamiliar with C/C++ build systems I found it very hard to get anything configured.
In contrast, I tried to learn CMake after. Despite my gripes about the CMake language itself, I found it relatively straightforward to do everything I wanted. Docs, backwards-compatibility, and LLMs made it all easy to set up. I have a hybrid C++/Rust project that compiles to desktop/WASM with debug/release builds.
When the build system for Zig stabilizes I'm sure things will be better, but the breaking changes are rough based on my recent experience.
Just to start some discussion about the actual API and not the breaking change aspect of it:
I find the `Reader.stream(writer, limit)` and `Reader.streamRemaining(writer)` functions to be especially elegant to build a push-based data transformation pipeline (like GREP or compression/encryption). You just implement a Writer interface for your state machine and dump the output into another Writer and you don't have to care about how the bytes come and how they leave (be it a socket or shared memory or file) -- you just set the buffer sizes (which you can even set to zero as I gather!)
`Writer.sendFile()` is also nice, I don't know of any other stream abstraction that provides this primitive in the "generic interface", you usually have to downcast the stream to a "FileStream" and work on the file descriptor directly.
re: sendfile in the interface - that's important because while downcasting the stream to "FileStream" would work if your pipeline looks like A -> B, it falls apart the moment you introduce an item in the middle (A -> B -> C). Meanwhile I have a demo of File -> tar -> HTTP (Transfer-Encoding: chunked) -> Socket and the direct fd-to-fd copies make it all the way through the chain!
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.
I'm definitely looking at the example set by hare with interest[0]. Also unironically love Shrek. I once hosted a viewing party of Shrek Retold[1] in my tiny NYC apartment :D
This is why I'm surprised when production projects, like bun, choose to use zig. I don't think the language itself is a bad choice (although I do disagree qith some of the design decisions), but having to make substantial changes when there are breaking changes like this because the language is pre-1.0 every so often in a large code base isn't something I would want to deal with.
In reality it makes little difference whether source code needs to be fixed because of a breaking language or dependency update. Even in C/C++ I need to go over my code whenever I update to a new compiler version because of new warnings.
I never wrote single line of zig code, but I follow it as an interesting language, so I might be missing something fundamental.
I agree that this looks extremely breaking, and feel like providing no compatibility layer fragments community, especially when you might have some unmaintained dependency somewhere that will never be updated.
there were similar situations when in rust some core libraries decided to alter its interfaces.
but I believe rust approach with editions is brilliant and could be adapter to other languages like zig.
It might be nice if language and library authors at least included a really good prompt detailing all the required changes so an LLM can take a first pass at fixing everything.
Even better if it can be done with a deterministic codemod, but a prompt is easier to write.
something that I don't understand about the actual API:
I maintain the zigler library, and one thing that was useful about the old async "colored-but-not-really" functions was that they implicitly tolerate having internal suspend points (detail: https://www.youtube.com/watch?v=lDfjdGva3NE&t=1819s) -- I'm not sure if having IO be a passed parameter will still let me do that? Can users build their own functions with yield points? And will you be able to jump out of the frame of a function and give control back to the executor, to let it resume later?
As you're aware, that feature of the language ("stackless coroutines", "generators", "rewriting function logic into a state machine") was regressed. At first, this new IO interface won't have that capability.
However, as a followup issue, I'd like to reintroduce it, potentially in more low-level manner, for use inside IO implementations. Combined with restricted function pointers, this will allow functions that can suspend to pass through runtime-known function pointer boundaries - something that was terribly clunky before to the point that it compromised the entire design. This means that, again, the same IO interface usage code will be able to be reused, including when the implementation uses suspend points, and the automatic calling convention rewriting will be able to propagate through the interface into the usage code.
thanks! I would have asked on stream but I'm in a bit of a different timezone than usual so my ability to track livestream times competently has regressed.
As an aside, do you think in the near future there will be a "guide to building a compiler backend" either in-project or by the community?
I'm not aware of any such effort. The only thing of relevance I have to share on the topic is the new Legalize pass which can ease the job of contributing a backend, because it restricts the subset of AIR instructions that a backend must lower based on a set of features the backend opts into. For example, it can scalarize all the vectors so the backend does not have to be vector-aware.
Not the original poster, and I don't have very high hopes that these will be revisited, but some things I would like to see revisited are:
- ability to define anonymous functions without having to put it inside an anonymous struct. I get the argument against closures (even if I don't fully agree with it), but not having first class support for anonymous functions feels pretty regressive for a modern language
- have a way to include payload data with errors. Or at the very least, define an idiomatic pattern for handling cases where you have additional data for an error
- allow struct fields to be private
- bring back async support in some form (this one I do have some hope for)
I would like to have some kind of interfaces instead of having to always use anytype, so compiler errors will appear in the call site instead of the called function body
(That link seems to show the "unused local variable" error line twice for me; that's some kind of bug with this zigbin service and does not reproduce when running the Zig compiler normally.)
I think this should be a warning on debug builds and an error on release builds, but it's a relatively minor thing and not a deal breaker by any means.
If this is the worst thing that people would like to see revisited, Zig must be doing amazingly well.
> but it's a relatively minor thing and not a deal breaker by any means.
It totally breaks my normal workflow. I don’t use zig at all because of this misfeature. Warn in debug and error on release builds would be strange but fine.
As someone zig-curious who has to jump around between ruby and elixir, if there’s a nice linting tool that can notify and maybe auto-correct, then I don’t see this as an issue
One issue I have with the old reader/writer pattern is that it is not easy to store them in a struct. Reader and writer are passed into a function as 'anytype' which implements any of the read() or write() functions. Often time in a struct's init() function, I want to take in a reader/writer and store it for later use. It's close to impossible since I don't know what type of the field of the struct to store them.
Does the new change make it easier to store reader/writer in a struct?
Nice video. I especially like the new 'labeled switch' feature providing a freeform control flow, and the watch/incremental compile feature. I used to use Rust's watchexec to do zig build on changes; now the watch feature is built natively in zig. The IO based async/await stuff seems to be the right direction; it's following the familiar Allocator pattern. The integrated fuzz testing into the compiler tool chain is fantastic; I can write much less unit tests now.
Zig.day looks like a wonderful way to do laid back hackathons. Looking forward to one coming up.
You'll have to write C API wrappers around your C++ libraries to access them from Zig, but other then that I can cross-compile my mixed C/C++/Zig projects using Windows APIs like DXGI/D3D/WASAPI with `zig build -Dtarget=x86_64-windows` from a Mac with the vanilla Zig toolchain.
...you don't even need to port anything in your C/C++ project to Zig, just integrate `zig cc` as C/C++ compiler into your existing build system, or port your build system files to build.zig.
Yes, the C++ code compiles just fine, but to call into C++ APIs from Zig you'll need a C API wrapper (and the same is true for ObjC APIs). Not an issue of course for pure C++ projects when the Zig toolchain is just used for cross-compiling.
That doesn't matter much when it's specifically the C/C++ compiler vendors who don't care about fixing the cross-compilation problem. It would be trivial for C/C++ compiler vendors to make cross-compilation as simple as with the Zig toolchain, but they don't care about the topic and that's why it doesn't happen.
Fast forward a few decades to today and the best solution to cross-compile C/C++ projects is the Zig toolchain (and isn't that kinda weird? A "foreign" toolchain coming along fixing one of the biggest problems in the C/C++ ecosystem just like that as a "side quest"?)
The problem with cross-compiling for Windows or macOS as targets are the runtimes (sometimes required during compilation or building), not the cross-compiling. This also has nothing to do with C/C++ as a language.
We build for Linux and Windows on Linux using gcc/mingw and don't have any fundamental issues doing so. On macOS we need the headers & libraries for macOS, we have to do those inside a VM.
I'd be extremely surprised if you can cross-compile Zig for macOS on a non-macOS platform, unless it doesn't use any macOS native frameworks at any level.
From all that I've experienced in the past few weeks dealing with C projects and various build systems and operating systems, I suspect that using Zig would work perfectly as an easy cross-platform alternative to CMake. Until I open up my code in VS Code and the C/C++ plugin just doesn't work, no auto-completion, no go-to-definition, syntax highlighting is broken, etc., and all because it can't find the files in places it ordinarily expects them to be. And maybe there will be some hacky way to fix it with a setting for the VS Code plugin, but likely not.
I'm not saying this is the case, but literally none of the setups I tried feels non-hacky so far, and every one of them has at least one noticable problem during development. I truly miss the days of writing apps for a single platform using its own native build tools. Maybe that's what I'll do: write this as a native Windows app using Visual Studio (ugh, such an awful editor though) and then if I get sales, port it to Mac OS X 10 using Xcode.app, and compile it for Linux inside WSL with GCC 15.
Maybe I worded it wrong. I want to develop my app in VS Code. I have gotten so very used to everything about how VS Code works over the past 10 years, that Visual Studio feels so unintuitive and backwards and weird. But VS is the king of C development on Windows apparently. That said, I've made some progress getting VS Code to work with the official Microsoft plugins for both C/C++ and CMake, both inside WSL and outside of it, though nothing that doesn't feel somewhat hacky.
Sadly, the C++ language does not exist in a vacuum.
In fact, it exists in a world which contains "an ecosystem", tooling, opinionated build systems, various incompatible compilers, and mountains of legacy baggage, and all of these influence the daily experience of programmers using the language.
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?
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.
Evem not knowing the history of Watergate, it's a meme now. A few months ago in a spanish speaking country there was a case known as "Rolexgate": https://en.wikipedia.org/wiki/Rolexgate
As a data point: I can honestly say I’ve never heard of Gamergate before this comment, and I am a 31-year-old white male. I did read a book on Watergate when I was in my teens, though.
GamerGate is well worth understanding. While some of the details are unique to the situation, it’s provided a template for right-wing radicalisation that’s been employed multiple times since. There’s also an entertaining “where are they now” aspect where some people have been almost forgotten and some are in the White House. KotakoInAction is still going and has (inevitably) morphed into a bunch of people complaining about the Lūgenpresse.
Let’s just say that I think it’s an important event and understanding how a guy harassing his ex-girlfriend became a formative moment in alt-right history is fascinating, but I really don’t want to get drawn into arguments with anyone who’s still drinking that particular kool-aid.
I thought the series made by some journalist was very interesting, I don't remember her name, and I don't remember so much of gamergate. But I'm definitely not a core part of either group there..
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!
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++)
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.
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.
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
I can relate, because I have so much things in years that broke left and right, but at the same time (except if you are talking about pre/alphas) I think is unhealthy to be vary of breaking changes.
A language, in special, should be able to do it. Extreme compatibility is the way to make the mistake that is C.
A breaking change that fix something is a investing that extend infinity to the feature.
Fear to do it, like in C, is how you accumulate errors, mistakes, millions of dollars wasted, because is also compound debt.
P.D: I think langs should be fast to break pre 1.0, and maybe have room to do it each 5/7 years. Despite the debacle of Python (that is in fact more reflective of python than of breaking), there should be possible to make a relatively painless sunsetting with good caring
The problem I have with python2 vs python3 wasn't breaking backward compatibility, but that their "solution" for UNICODE strings is such a weird mess (treating string- and byte-streams as something completely separate instead of treating strings as UTF-8 encoded views on byte streams) The only string encoding that matters today is UTF-8, all others are relics from the early 90s and the sooner we get rid of those the better - e.g. Python caused a whole lot of pain for a solution that would have been useful 30 years ago, but not today.
There's another problem that's affecting more than just Python too: grapheme clusters. It turns out that even a sequence of scalars (code points excluding surrogates) isn't always a safe abstraction anymore.
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.
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.
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 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.
I know how freestanding works, and I agree that Rust's "nostd" is much more thought out than C/C++'s freestanding, however
> This is roughly analogous to Rust's nostd.
"freestanding" is actually worse that this. It means that the compiler can't even assume things about memcpy and optimize it out (as on gcc it implies -fno-builtin), which pessimizes a lot of idiomatic code (eg. serialization).
The "-nostdlib" option is usually what one wants in many cases (don't link against libc but still provide standard C and C++ headers), such as when compiling privileged code with -mgeneral-regs only and such. This way you can benefit from <chrono>, etc.
If you are writing userland code you should be using a toolchain for this, instead of relying of freestanding/nostdlib which are geared towards kernel code and towards working around defective toolchains.
If you are targeting armv4t/armv5/armv6k+vfp (or armv7 but not optimized for it) for Aarch32, or Armv8.0-A and are fine with newlib, then devkitARM and devkitA64, respectively, get the job done and ship GCC 15.1.
There is also devkitPPC, shipping with the same toolchain (and which additionally has some Obj-C support iirc).
Custom patches to newlib and consorts (https://github.com/devkitPro/buildscripts/) introduce hooks and WEAK functions that allow to implement standard library functions on almost any platform, on a platform library basis or even on a per-program basis (with some restrictions on lock sizes).
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.
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.
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.
In deployments where C and C++ are the only two options available, and management is not willing to get another one, C++ still has lots of improvements over, as "Typescript for C".
Building our own types was a rite of passage for C++ programming back in the early 1990's, and university curriculums for C++ as well.
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.
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.
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.
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??
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
> 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.
easy peasy. you've resolved the coloring boundary.
now, if you want to be a library writer, yeah, you have to color your functions if you don't want to be an asshole, but for the 95% use case this is not function coloring.
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.
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.
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.
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.
the only two new feature syntaxes in about six releases have been multiple iterations in for loops and continue in switches? maybe reified tuple types too (not just implicit) and destructuring tuples.
a few things have been removed, too. and async/suspend/nosuspend/await, usingnamesplace are headed for the woodchipper.
I guess, two macro systems, ML type system, affine types, crates using nightly features, having a hard time keeping up with every six weeks feature drops.
I get two macro systems, but a coherent type system seems simpler to understand. The existence of "regular void" proposals seems to underscore that the "easy" C type system's incoherence doesn't end up being easy to work with or reason about.
And I don't see "crates using nightly features" as somehow a language complexity. Are we counting "Three different compilers with their own quirks" as a C++ complexity? Nor is the six week cadence a complexity. When naked functions stabilized a handful of people went "Hooray" and nearly everybody else doesn't care. And that's not even a feature in standard C++. You have to go read your vendor instructions and do it separately each time. "Yay!".
I like both languages, those are the issues where I see someone looking from outside and having such complexity claim as the OP.
The ecosystem is part of what means to use a specific language, though.
Yeah, having to guess what standards and extensions each C and C++ compiler implement, is also an issue with them, and will eventually come to Rust as implementations eventually come up, originally there was only CFront and UNIX System V compilers.
Odin's IO is quite messy. I have strong feeling it evolved as an adhoc solution to tackle development requirements without much thought. I'm happy Andy wants to fix high level (and very important) interfaces while being in pre 1.0.
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?
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.
> 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?
This is a few months after `git init`. You can see I was really just working on the parser, with a toy example to get things started.
Over time, I merged contributions that made minor changes and shuffled things around, and these APIs evolved to kind of work okay. But nobody really considered "the Zig IO stack" as a whole and put in design effort. That is happening for the first time right now.
This is how programming languages are constructed. Things evolve slowly over time, and periodically you have to reevaluate things and do major reworkings.
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!
> 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.
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.
> 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.
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 or Node.js it's quite bare bones.
Fair, I was mentally comparing to Go. I was a bit disappointed there wasn't more wrappers around basic OS stuff. Go stdlib wraps everything and does its best to make stuff cross-platform.
In my specific case I was trying to send some DNS messages. I went the route of linking libc and using the posix data structures for DNS messages and struggled quite a bit how to map the C data structures to my program.
This kind of thing is a big barrier to adoption unfortunately.
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.
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.
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.
Static types help to find what needs to be fixed. Something like 'go fix' would be useful for fixing them. Apparently something like that is being considered for zig.
I don't think even those are particularly short periods. TestCase.assertEquals() was deprecated in Python 3.2 (February 2011) and removed in Python 3.12 (October 2023). 12 ⅔ years to get rid of a silly alias because it's a breaking change (of a single character).
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.
Every time I touched Zig, examples I found on the internet were no longer working. I worked on a project for a while and then the stuff I used was deprecated / broken on the newer version.
I like Zig, but I'm waiting for it to become somewhat stable, because the amount of breaking changes feels pretty significant. I suppose that's the price of progress.
That is because the language is pre-1.0.
The new language I follow a lot is Mojo, it also has this problem.
I think the only way to follow a new (unstable) language is to join whatever community where the conversation happens; otherwise, what you think you know about the language will become outdated pretty quickly.
It deeply bothers me that the zig team/community has been aggressively marketing this language while constantly making breaking changes without even providing migration tools. This is user hostile behavior. They are creating extra work for downstream users with minimal gain.
Let's take this change as an example. If I already wrote a program that used the old apis and meets my needs what is the benefit of this change for me? Now I have to go back and rewrite my old code and I might introduce a new bug in the migration, especially if I don't understand all of the nuance in the difference between the apis. Even if I agree that the new apis are better, the cost of migration might outweigh the benefits, but I am forced in to the migration or forking the compiler, which both might be bad choices for me.
It is not necessary to do this. They could, for example, have versioned stdlib and then maybe all I need to is pin my stdlib version. One complaint is that having multiple standard libraries causes more maintenance burden, but why should that be the primary concern? What is the cost to the maintainer vs. the cost to the community. If you make 1000 users spend an hour migrating their code, are you really going to save 1000 hours of maintenance burden?
Moreover, if the zig team wrote code with the assumption that they can never get rid of it, perhaps they wouldn't make so many design mistakes that all of these breaking changes become inevitable.
If I wrote a program in zig, I would feel obligated to also learn how to bootstrap it so that I wouldn't be subject to unwanted breaking changes. But then I see that bootstrapping involves some bizarre wasm hack instead of the tried and true bootstrapping approach of writing a simple first pass compiler in c (or some other language) and I am reminded again why I would never choose this language.
I can't see how the team or community are aggressively marketing Zig. There's a lot of buzz around some projects written in Zig, such as Bun and TigerBeetle. Andrew Kelly isn't even on Twitter or X. It almost sounds like you're talking about the 14-year-old indie devs sharing their 1M MRR apps? It's a non-profit, created by real people working very hard to make something valuable for the rest of us... People who could easily be driving Lambos with their talent.
When someone creates something others want, it'll inevitably become popular.
If your app is stable, could you not keep using the version you're happy with?
> I see that bootstrapping involves some bizarre wasm hack instead of the tried and true bootstrapping approach of writing a simple first pass compiler in c (or some other language) and I am reminded again why I would never choose this language.
The hack allows the compiler to be maintained in Zig, compiled to WASM (a supported backend), and then bootstrapped with only a wasm interpreter… and one is provided in a single C file (I believe… but haven’t looked in a while).
This is a much nicer situation than most other bootstrap scenarios. All the SMLs, for instance, require you to have a whole other SML! MoscowML bootstraps with an included Caml interpreter… but it’s not sufficient to compile MLton.
We're not talking about Python 2 here. This is a pre-1.0 language. As an occasional dabbler in the language, I implicitly understand this to mean that there will be breaking changes, and I have made peace with that.
Looking over the changes, they seem wise and well justified. Fixing my old codebases will be annoying, but I don't mind the annoyance if a better language comes out the other end.
> zig team/community has been aggressively marketing this language
...I think the only thing that's aggressively marketed is that the Zig team isn't afraid of big and controversial breaking changes ;) If you can't handle that, then Zig currently isn't right for you, it's as simple as that.
> They could, for example, have versioned stdlib and then maybe all I need to is pin my stdlib version.
That really only makes sense for after 1.0, and even after that only for stdlib APIs that are out of the experimental phase.
But post 1.x some sort of migration support for breaking changes would indeed be much more useful than trying to prevent breaking changes at all cost.
> and I am reminded again why I would never choose this language.
...then why even write such a lengthy comment? Just ignore Zig and move on... it's not like there's plenty of other languages which might better fit your taste.
anyways downloads of older versions are generally available!! like this whole bootstrapping freakout is weird. and anyways its funny to say the wasm build thing is a hack versus building with c. have you seen cmake? that whole thing is a hack.
I maintain a library to interface zig with elixir and the breaking changes have not been a big deal. As a part of the library I have maintain a zig parser (the official parser in the langref is not up to date) and I scan the entire zig codebase against my parser to make sure it doesn't trip up on anything. Also I can't use zig fmt to keep up because some of the code is templated and embedded in Elixir. The last two semver minor updates, the net total amount of changes I have had to do to keep up with the language took me maybe an hour? Also subjectively, I feel like the breaking changes that affect me have been fewer and easier to deal with since the early days. The bulk of the delay in updating the library was chipping away at things that i had put off since the last update (also i don't use the library in $DAYJOB since I "quit tech", though I do vibecode solutions for myself).
Point being, I feel like a lot of the gripes about zig changing here and there are really by folks who aren't really daily users, just people who see a !!breaking change!! announcement and pile on.
Though, I do sympathize with newcomers because the memory of the internet is pinned to various older versions with lots of demo code that 'just doesn't work' and of course that means LLMs too, in the long run. Hopefully zig doesn't get stuck past the global knowledge/popularity LLM-cycle cutoff. I don't think it will.
The problem for newcomers is something I faced when trying to use Zig, particularly for the build system. I heard a lot about how much nicer the build system is in Zig compared to other tools. However, as someone unfamiliar with C/C++ build systems I found it very hard to get anything configured.
In contrast, I tried to learn CMake after. Despite my gripes about the CMake language itself, I found it relatively straightforward to do everything I wanted. Docs, backwards-compatibility, and LLMs made it all easy to set up. I have a hybrid C++/Rust project that compiles to desktop/WASM with debug/release builds.
When the build system for Zig stabilizes I'm sure things will be better, but the breaking changes are rough based on my recent experience.
Zig's build system is in zig code. Cmake/make/ninja/meson are not. That's a notable difference.
My initial take on the zig stuff is that it's a bit complex ...
Just to start some discussion about the actual API and not the breaking change aspect of it:
I find the `Reader.stream(writer, limit)` and `Reader.streamRemaining(writer)` functions to be especially elegant to build a push-based data transformation pipeline (like GREP or compression/encryption). You just implement a Writer interface for your state machine and dump the output into another Writer and you don't have to care about how the bytes come and how they leave (be it a socket or shared memory or file) -- you just set the buffer sizes (which you can even set to zero as I gather!)
`Writer.sendFile()` is also nice, I don't know of any other stream abstraction that provides this primitive in the "generic interface", you usually have to downcast the stream to a "FileStream" and work on the file descriptor directly.
re: sendfile in the interface - that's important because while downcasting the stream to "FileStream" would work if your pipeline looks like A -> B, it falls apart the moment you introduce an item in the middle (A -> B -> C). Meanwhile I have a demo of File -> tar -> HTTP (Transfer-Encoding: chunked) -> Socket and the direct fd-to-fd copies make it all the way through the chain!
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.
>-Lord Farquaad
[0] https://github.com/mtlynch/zenith/pull/90/files#diff-f87bb35...
[1] https://ziglang.org/download/0.12.0/release-notes.html
I'm definitely looking at the example set by hare with interest[0]. Also unironically love Shrek. I once hosted a viewing party of Shrek Retold[1] in my tiny NYC apartment :D
[0] https://harelang.org/blog/2025-06-11-hare-update/
[1] https://www.youtube.com/watch?v=pM70TROZQsI
Good to hear! (on all fronts)
An automated tool would be great, but even good documentation with examples of before vs. after code snippets would go a long way.
This is why I'm surprised when production projects, like bun, choose to use zig. I don't think the language itself is a bad choice (although I do disagree qith some of the design decisions), but having to make substantial changes when there are breaking changes like this because the language is pre-1.0 every so often in a large code base isn't something I would want to deal with.
Zig just caught up with the practice that runs rampant in JavaScript land ;)
this comparison doesn't really make sense since JS as a language keeps a lot of old baggage to maintain backwards compatibility.
In reality it makes little difference whether source code needs to be fixed because of a breaking language or dependency update. Even in C/C++ I need to go over my code whenever I update to a new compiler version because of new warnings.
And that is why when no one pays the budget for doing tooling upgrades in big corps, the tooling never gets updated.
maybe... it's got some really good things going for it that are worth the pain.
I never wrote single line of zig code, but I follow it as an interesting language, so I might be missing something fundamental.
I agree that this looks extremely breaking, and feel like providing no compatibility layer fragments community, especially when you might have some unmaintained dependency somewhere that will never be updated.
there were similar situations when in rust some core libraries decided to alter its interfaces.
but I believe rust approach with editions is brilliant and could be adapter to other languages like zig.
It might be nice if language and library authors at least included a really good prompt detailing all the required changes so an LLM can take a first pass at fixing everything.
Even better if it can be done with a deterministic codemod, but a prompt is easier to write.
Shoehorning AI/LLMs into every possible thing in existence is counterproductive and wouldn't help in this situation.
I was hesitant to post it, but migrations are one of the good use cases IMO. They're very mechanical and easy for LLM to follow.
For context this was presented, alongside other things, in the Zig Roadmap 2026 stream.
VOD: https://youtu.be/x3hOiOcbgeA
something that I don't understand about the actual API:
I maintain the zigler library, and one thing that was useful about the old async "colored-but-not-really" functions was that they implicitly tolerate having internal suspend points (detail: https://www.youtube.com/watch?v=lDfjdGva3NE&t=1819s) -- I'm not sure if having IO be a passed parameter will still let me do that? Can users build their own functions with yield points? And will you be able to jump out of the frame of a function and give control back to the executor, to let it resume later?
Hi Isaac, good to (virtually) see you.
As you're aware, that feature of the language ("stackless coroutines", "generators", "rewriting function logic into a state machine") was regressed. At first, this new IO interface won't have that capability.
However, as a followup issue, I'd like to reintroduce it, potentially in more low-level manner, for use inside IO implementations. Combined with restricted function pointers, this will allow functions that can suspend to pass through runtime-known function pointer boundaries - something that was terribly clunky before to the point that it compromised the entire design. This means that, again, the same IO interface usage code will be able to be reused, including when the implementation uses suspend points, and the automatic calling convention rewriting will be able to propagate through the interface into the usage code.
The issue to track is: https://github.com/ziglang/zig/issues/23446
I'll add that I'm still keen on the previous suspend/resume keywords and semantics as a solution to this issue.
thanks! I would have asked on stream but I'm in a bit of a different timezone than usual so my ability to track livestream times competently has regressed.
As an aside, do you think in the near future there will be a "guide to building a compiler backend" either in-project or by the community?
I'm not aware of any such effort. The only thing of relevance I have to share on the topic is the new Legalize pass which can ease the job of contributing a backend, because it restricts the subset of AIR instructions that a backend must lower based on a set of features the backend opts into. For example, it can scalarize all the vectors so the backend does not have to be vector-aware.
A big change like this makes me hopeful Zig may revisit and improve other design choices in the future.
Could you elaborate on the choices you'd like revisited?
Not the original poster, and I don't have very high hopes that these will be revisited, but some things I would like to see revisited are:
- ability to define anonymous functions without having to put it inside an anonymous struct. I get the argument against closures (even if I don't fully agree with it), but not having first class support for anonymous functions feels pretty regressive for a modern language
- have a way to include payload data with errors. Or at the very least, define an idiomatic pattern for handling cases where you have additional data for an error
- allow struct fields to be private
- bring back async support in some form (this one I do have some hope for)
I would like to have some kind of interfaces instead of having to always use anytype, so compiler errors will appear in the call site instead of the called function body
Unused variables stops all further compilation, so that even future errors can't be seen until the variable is used.
This is simply not true. See https://zigbin.io/f57b94/run.
(That link seems to show the "unused local variable" error line twice for me; that's some kind of bug with this zigbin service and does not reproduce when running the Zig compiler normally.)
Meh.
I think this should be a warning on debug builds and an error on release builds, but it's a relatively minor thing and not a deal breaker by any means.
If this is the worst thing that people would like to see revisited, Zig must be doing amazingly well.
> but it's a relatively minor thing and not a deal breaker by any means.
It totally breaks my normal workflow. I don’t use zig at all because of this misfeature. Warn in debug and error on release builds would be strange but fine.
Zig Roadmap 2026 : https://www.youtube.com/watch?v=x3hOiOcbgeA
Is there non-video version?
https://ziglang.org/download/0.14.0/release-notes.html
As someone zig-curious who has to jump around between ruby and elixir, if there’s a nice linting tool that can notify and maybe auto-correct, then I don’t see this as an issue
One issue I have with the old reader/writer pattern is that it is not easy to store them in a struct. Reader and writer are passed into a function as 'anytype' which implements any of the read() or write() functions. Often time in a struct's init() function, I want to take in a reader/writer and store it for later use. It's close to impossible since I don't know what type of the field of the struct to store them.
Does the new change make it easier to store reader/writer in a struct?
I recommend watch this video https://youtu.be/x3hOiOcbgeA
Nice video. I especially like the new 'labeled switch' feature providing a freeform control flow, and the watch/incremental compile feature. I used to use Rust's watchexec to do zig build on changes; now the watch feature is built natively in zig. The IO based async/await stuff seems to be the right direction; it's following the familiar Allocator pattern. The integrated fuzz testing into the compiler tool chain is fantastic; I can write much less unit tests now.
Zig.day looks like a wonderful way to do laid back hackathons. Looking forward to one coming up.
Yes, that is precisely what "non-generic" means.
That's excellent! Thanks for the changes.
By the title I thought that they were going to implement this,
https://github.com/ziglang/zig/issues/5973
I don't mind breaking changes if I can fix them within a day.
What bothers me with C/C++ is how difficult it is to cross compile a simple Windows + SDL app from inside WSL without MSVC installed.
I've spent weeks on this.
If Zig saves me from that nightmare, and still lets me use C++ libraries, I will gladly switch over to it.
I have been doing cross compiling stuff since the Symbian glorious days.
Some people really love to make their life harder, as in your example, targeting Windows from inside WSL, instead Windows proper.
You'll have to write C API wrappers around your C++ libraries to access them from Zig, but other then that I can cross-compile my mixed C/C++/Zig projects using Windows APIs like DXGI/D3D/WASAPI with `zig build -Dtarget=x86_64-windows` from a Mac with the vanilla Zig toolchain.
...you don't even need to port anything in your C/C++ project to Zig, just integrate `zig cc` as C/C++ compiler into your existing build system, or port your build system files to build.zig.
That works out great, since all the libraries I need are C or have C wrappers anyway. I might actually do this, thanks.
Wait what. Shouldn’t zig crosscompile C++ just fine?
Yes, the C++ code compiles just fine, but to call into C++ APIs from Zig you'll need a C API wrapper (and the same is true for ObjC APIs). Not an issue of course for pure C++ projects when the Zig toolchain is just used for cross-compiling.
Oooh yeah that makes sense.
None of which has anything to do with C++ the language.
That doesn't matter much when it's specifically the C/C++ compiler vendors who don't care about fixing the cross-compilation problem. It would be trivial for C/C++ compiler vendors to make cross-compilation as simple as with the Zig toolchain, but they don't care about the topic and that's why it doesn't happen.
Fast forward a few decades to today and the best solution to cross-compile C/C++ projects is the Zig toolchain (and isn't that kinda weird? A "foreign" toolchain coming along fixing one of the biggest problems in the C/C++ ecosystem just like that as a "side quest"?)
The problem with cross-compiling for Windows or macOS as targets are the runtimes (sometimes required during compilation or building), not the cross-compiling. This also has nothing to do with C/C++ as a language.
We build for Linux and Windows on Linux using gcc/mingw and don't have any fundamental issues doing so. On macOS we need the headers & libraries for macOS, we have to do those inside a VM.
I'd be extremely surprised if you can cross-compile Zig for macOS on a non-macOS platform, unless it doesn't use any macOS native frameworks at any level.
\<rant>
From all that I've experienced in the past few weeks dealing with C projects and various build systems and operating systems, I suspect that using Zig would work perfectly as an easy cross-platform alternative to CMake. Until I open up my code in VS Code and the C/C++ plugin just doesn't work, no auto-completion, no go-to-definition, syntax highlighting is broken, etc., and all because it can't find the files in places it ordinarily expects them to be. And maybe there will be some hacky way to fix it with a setting for the VS Code plugin, but likely not.
I'm not saying this is the case, but literally none of the setups I tried feels non-hacky so far, and every one of them has at least one noticable problem during development. I truly miss the days of writing apps for a single platform using its own native build tools. Maybe that's what I'll do: write this as a native Windows app using Visual Studio (ugh, such an awful editor though) and then if I get sales, port it to Mac OS X 10 using Xcode.app, and compile it for Linux inside WSL with GCC 15.
\</rant>
Pretty sure that Visual Studio is not a crossplatform toolkit. Why would you start there?
Maybe I worded it wrong. I want to develop my app in VS Code. I have gotten so very used to everything about how VS Code works over the past 10 years, that Visual Studio feels so unintuitive and backwards and weird. But VS is the king of C development on Windows apparently. That said, I've made some progress getting VS Code to work with the official Microsoft plugins for both C/C++ and CMake, both inside WSL and outside of it, though nothing that doesn't feel somewhat hacky.
In theory yes, in practice that's irrelevant unless you can show someone has done it, and nobody has in 40+ years as far as I know
WSL hasn't existed for that long. So I am not sure what "it" is ...
Sadly, the C++ language does not exist in a vacuum.
In fact, it exists in a world which contains "an ecosystem", tooling, opinionated build systems, various incompatible compilers, and mountains of legacy baggage, and all of these influence the daily experience of programmers using the language.
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?
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.
Nice, I wonder if adapting it for this change would make sense?
its a really huge change
Isn't that an argument for automated fixing?
huge in complexity. though looking at it i see andrew has made a "polyfill" ish thing to give ppl a way out for a ?(a few)? releases
Is Writergate a technical term or a reference to Watergate?
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
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.
> the original Watergate scandal
You mean the Watergate-gate?
It also deeply confuses international readers. Need to learn American history to to get an idea of what is being conveyed.
Evem not knowing the history of Watergate, it's a meme now. A few months ago in a spanish speaking country there was a case known as "Rolexgate": https://en.wikipedia.org/wiki/Rolexgate
Weird that anyone is downvoting this, as it’s a precisely correct answer.
[flagged]
Gamergate was not the first scandal (post-Watergate) to use -gate: https://en.m.wikipedia.org/wiki/List_of_-gate_scandals_and_c...
As a data point: I can honestly say I’ve never heard of Gamergate before this comment, and I am a 31-year-old white male. I did read a book on Watergate when I was in my teens, though.
GamerGate is well worth understanding. While some of the details are unique to the situation, it’s provided a template for right-wing radicalisation that’s been employed multiple times since. There’s also an entertaining “where are they now” aspect where some people have been almost forgotten and some are in the White House. KotakoInAction is still going and has (inevitably) morphed into a bunch of people complaining about the Lūgenpresse.
This comment smells like LLM output, you have said a lot, but I didn't understand anything.
Let’s just say that I think it’s an important event and understanding how a guy harassing his ex-girlfriend became a formative moment in alt-right history is fascinating, but I really don’t want to get drawn into arguments with anyone who’s still drinking that particular kool-aid.
I thought the series made by some journalist was very interesting, I don't remember her name, and I don't remember so much of gamergate. But I'm definitely not a core part of either group there..
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!
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++)
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.
It also helps job prospects of Zig programmers within organizations that have already adopted Zig -- more breakage, more job security.
advances the purposes of cynics as well, so big bonus.
Do you honestly believe what you're saying
> 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.
Pandas (different world: Python) arguably peaked in hype (if not popularity) before reaching 1.0
0.x doesn't say as much as it used to 20 years ago, many fine projects keep it for way too long.
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
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.
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
I can relate, because I have so much things in years that broke left and right, but at the same time (except if you are talking about pre/alphas) I think is unhealthy to be vary of breaking changes.
A language, in special, should be able to do it. Extreme compatibility is the way to make the mistake that is C.
A breaking change that fix something is a investing that extend infinity to the feature.
Fear to do it, like in C, is how you accumulate errors, mistakes, millions of dollars wasted, because is also compound debt.
P.D: I think langs should be fast to break pre 1.0, and maybe have room to do it each 5/7 years. Despite the debacle of Python (that is in fact more reflective of python than of breaking), there should be possible to make a relatively painless sunsetting with good caring
The problem I have with python2 vs python3 wasn't breaking backward compatibility, but that their "solution" for UNICODE strings is such a weird mess (treating string- and byte-streams as something completely separate instead of treating strings as UTF-8 encoded views on byte streams) The only string encoding that matters today is UTF-8, all others are relics from the early 90s and the sooner we get rid of those the better - e.g. Python caused a whole lot of pain for a solution that would have been useful 30 years ago, but not today.
There's another problem that's affecting more than just Python too: grapheme clusters. It turns out that even a sequence of scalars (code points excluding surrogates) isn't always a safe abstraction anymore.
But at some point it'll be ready. Might it be worth it then?
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.
Dude Zig is clearly pre 1.0. It can introduce breaking changes with every commit and rightfully so. I mean d'oh it's Not ready for Prime Time.
Zig uses ZeroVer so don't expect it to ever hit 1.0.
https://0ver.org/
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.
I guess you're being Poe's lawwed but it's definitely a joke
Obligatory C is not a low level language: https://queue.acm.org/detail.cfm?id=3212479
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++.
> 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)
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.
I know how freestanding works, and I agree that Rust's "nostd" is much more thought out than C/C++'s freestanding, however
> This is roughly analogous to Rust's nostd.
"freestanding" is actually worse that this. It means that the compiler can't even assume things about memcpy and optimize it out (as on gcc it implies -fno-builtin), which pessimizes a lot of idiomatic code (eg. serialization).
The "-nostdlib" option is usually what one wants in many cases (don't link against libc but still provide standard C and C++ headers), such as when compiling privileged code with -mgeneral-regs only and such. This way you can benefit from <chrono>, etc.
If you are writing userland code you should be using a toolchain for this, instead of relying of freestanding/nostdlib which are geared towards kernel code and towards working around defective toolchains.
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.
If you are targeting armv4t/armv5/armv6k+vfp (or armv7 but not optimized for it) for Aarch32, or Armv8.0-A and are fine with newlib, then devkitARM and devkitA64, respectively, get the job done and ship GCC 15.1.
There is also devkitPPC, shipping with the same toolchain (and which additionally has some Obj-C support iirc).
Custom patches to newlib and consorts (https://github.com/devkitPro/buildscripts/) introduce hooks and WEAK functions that allow to implement standard library functions on almost any platform, on a platform library basis or even on a per-program basis (with some restrictions on lock sizes).
Indeed. My point was that freestanding is a strawman, with likely little relevance for embedded developers.
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.
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.
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.
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.
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/
In deployments where C and C++ are the only two options available, and management is not willing to get another one, C++ still has lots of improvements over, as "Typescript for C".
Building our own types was a rite of passage for C++ programming back in the early 1990's, and university curriculums for C++ as well.
Doesn't arduino use c++?
It does.
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.
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.
What if you want unbuffered IO?
I think you just initialize Reader and Writer with a zero-length buffer.
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.
Well it's about time.
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??
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
> 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.
As far as I know, Zig still wants their implementation of async to avoid function colouring.
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.
part of function coloring is "not being trivially resolvable". in this case the function coloring boundary is trivially resolvable.
easy peasy. you've resolved the coloring boundary.now, if you want to be a library writer, yeah, you have to color your functions if you don't want to be an asshole, but for the 95% use case this is not function coloring.
>> 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?
Much of the discussion is buried in the various GitHub issues related to async. I found something of a summary in this Reddit comment
https://www.reddit.com/r/Zig/comments/1d66gtp/comment/l6umbt...
iirc the llvm async operation does heap allocations?
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.
> 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.
https://jangafx.com/ https://odin-lang.org/showcase/
All the JangaFX products (such as EmberGen) are written in Odin.
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.
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.
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.
This feels out of touch with the actual industry today.
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.
What is "AI tooling"?
Ask Chat GPT, Claude or Gemini.
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.
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.
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.
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.
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.
Structured concurrency is a notoriously hard problem. This is part of Zig’s 4th attempt to get it right.
the only two new feature syntaxes in about six releases have been multiple iterations in for loops and continue in switches? maybe reified tuple types too (not just implicit) and destructuring tuples.
a few things have been removed, too. and async/suspend/nosuspend/await, usingnamesplace are headed for the woodchipper.
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.
How do you figure Rust is "as complex as C++" ?
I guess, two macro systems, ML type system, affine types, crates using nightly features, having a hard time keeping up with every six weeks feature drops.
I get two macro systems, but a coherent type system seems simpler to understand. The existence of "regular void" proposals seems to underscore that the "easy" C type system's incoherence doesn't end up being easy to work with or reason about.
And I don't see "crates using nightly features" as somehow a language complexity. Are we counting "Three different compilers with their own quirks" as a C++ complexity? Nor is the six week cadence a complexity. When naked functions stabilized a handful of people went "Hooray" and nearly everybody else doesn't care. And that's not even a feature in standard C++. You have to go read your vendor instructions and do it separately each time. "Yay!".
I like both languages, those are the issues where I see someone looking from outside and having such complexity claim as the OP.
The ecosystem is part of what means to use a specific language, though.
Yeah, having to guess what standards and extensions each C and C++ compiler implement, is also an issue with them, and will eventually come to Rust as implementations eventually come up, originally there was only CFront and UNIX System V compilers.
Odin's IO is quite messy. I have strong feeling it evolved as an adhoc solution to tackle development requirements without much thought. I'm happy Andy wants to fix high level (and very important) interfaces while being in pre 1.0.
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.
Not a killer app, but I think one thing you might consider is zig build.
Not a seller to me.
The killer application case is slow adoption inside ancient C and C++ codebases. That's the angle.
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.
It brings a lot of nice features, the potential for a healthier ecosystem, a unified build system, explicit allocators, explicit casts, and so on.
Ecosystems sell languages, not the other way around.
Yes, and you can use Zig in the C and C++ ecosystems, that's my point
For what though, what is the selling point to have IT accept it on the allowed toolchains.
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.
Zig is as safe as Modula-2 or Object Pascal, not the turning point of something like Swift or Rust.
I think pjmlps point is that Zig is not adding enough to be one of those safer successors.
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
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.
> 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?
Actually, nobody.
Here is the commit where Reader/Writer was introduced: https://github.com/ziglang/zig/commit/5e212db29cf9e2c06aba36...
This is a few months after `git init`. You can see I was really just working on the parser, with a toy example to get things started.
Over time, I merged contributions that made minor changes and shuffled things around, and these APIs evolved to kind of work okay. But nobody really considered "the Zig IO stack" as a whole and put in design effort. That is happening for the first time right now.
This is how programming languages are constructed. Things evolve slowly over time, and periodically you have to reevaluate things and do major reworkings.
Actually, I wasn’t intentionally designing anything.
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!
But some people are upset because you put the new bridge in a new location and now it's inconvenient for them?
Nah, they are upset because it brought more people, which increased the traffic...
https://www.wired.com/2014/06/wuwt-traffic-induced-demand/
Indeed, but to be fair, the old stack was done with a hand, not a foot!
A less experienced Andrew
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!
> 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.
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.
> Zig's status quo was no different from other languages
No-one's claiming that the people who wrote the other languages never put a foot wrong, so there's no claim of perfection to knock down with them.
> 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.
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 or Node.js it's quite bare bones.
Fair, I was mentally comparing to Go. I was a bit disappointed there wasn't more wrappers around basic OS stuff. Go stdlib wraps everything and does its best to make stuff cross-platform.
In my specific case I was trying to send some DNS messages. I went the route of linking libc and using the posix data structures for DNS messages and struggled quite a bit how to map the C data structures to my program.
This kind of thing is a big barrier to adoption unfortunately.
Go is literally a Kitchen Sink. I love it, but that stdlib comes with a runtime dependency.
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.
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.
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.
How many pre-release languages are you typically using though?
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
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.
Are people deploying production code in a language that is still in its 0.x version?
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
Some prod are more prod than the others.
> 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.
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
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.
Static types help to find what needs to be fixed. Something like 'go fix' would be useful for fixing them. Apparently something like that is being considered for zig.
Not having breaking changes every N months?
Each new minor Python 3.x version has plenty of deprecations followed by removals in the stdlib though.
I don't think even those are particularly short periods. TestCase.assertEquals() was deprecated in Python 3.2 (February 2011) and removed in Python 3.12 (October 2023). 12 ⅔ years to get rid of a silly alias because it's a breaking change (of a single character).
I dont but there are companies who trust the language (which is a good thing but also short sighted)
The risk isn't unique to shiny new languages
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.
well, in that case, the lasagna is still being cooked, until served (1.0), why question the chef?
let him cook
1.0s never land smoothly. That's when the herd of users comes and all the rough edges are actually found. The real 1.0 is 1.1.
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.
python is a really bad example. Code constantly stops working properly with language updates.
There was one language update that broke things, so much so that it was discussed for years. The julia breaking updates are myriad and ongoing
so are you telling me nothing breaks ever if you update python 3 minor versions? Because if so, I don't believe you. They also make breaking changes
how was python 2/3 again?
Famous because of how rare it was.
[flagged]
[flagged]
[flagged]
Be as sarcastic as you want. This is a feeling many developers probably share.
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.
And “I don’t care if you use it or not” is a feeling many other developers share so both are valid
Every time I touched Zig, examples I found on the internet were no longer working. I worked on a project for a while and then the stuff I used was deprecated / broken on the newer version.
I like Zig, but I'm waiting for it to become somewhat stable, because the amount of breaking changes feels pretty significant. I suppose that's the price of progress.
That is because the language is pre-1.0. The new language I follow a lot is Mojo, it also has this problem.
I think the only way to follow a new (unstable) language is to join whatever community where the conversation happens; otherwise, what you think you know about the language will become outdated pretty quickly.
It deeply bothers me that the zig team/community has been aggressively marketing this language while constantly making breaking changes without even providing migration tools. This is user hostile behavior. They are creating extra work for downstream users with minimal gain.
Let's take this change as an example. If I already wrote a program that used the old apis and meets my needs what is the benefit of this change for me? Now I have to go back and rewrite my old code and I might introduce a new bug in the migration, especially if I don't understand all of the nuance in the difference between the apis. Even if I agree that the new apis are better, the cost of migration might outweigh the benefits, but I am forced in to the migration or forking the compiler, which both might be bad choices for me.
It is not necessary to do this. They could, for example, have versioned stdlib and then maybe all I need to is pin my stdlib version. One complaint is that having multiple standard libraries causes more maintenance burden, but why should that be the primary concern? What is the cost to the maintainer vs. the cost to the community. If you make 1000 users spend an hour migrating their code, are you really going to save 1000 hours of maintenance burden?
Moreover, if the zig team wrote code with the assumption that they can never get rid of it, perhaps they wouldn't make so many design mistakes that all of these breaking changes become inevitable.
If I wrote a program in zig, I would feel obligated to also learn how to bootstrap it so that I wouldn't be subject to unwanted breaking changes. But then I see that bootstrapping involves some bizarre wasm hack instead of the tried and true bootstrapping approach of writing a simple first pass compiler in c (or some other language) and I am reminded again why I would never choose this language.
I can't see how the team or community are aggressively marketing Zig. There's a lot of buzz around some projects written in Zig, such as Bun and TigerBeetle. Andrew Kelly isn't even on Twitter or X. It almost sounds like you're talking about the 14-year-old indie devs sharing their 1M MRR apps? It's a non-profit, created by real people working very hard to make something valuable for the rest of us... People who could easily be driving Lambos with their talent.
When someone creates something others want, it'll inevitably become popular.
If your app is stable, could you not keep using the version you're happy with?
Zig is in development, devs who use it today must know it may break before 1.0. Your rant is unwarranted.
> I see that bootstrapping involves some bizarre wasm hack instead of the tried and true bootstrapping approach of writing a simple first pass compiler in c (or some other language) and I am reminded again why I would never choose this language.
The hack allows the compiler to be maintained in Zig, compiled to WASM (a supported backend), and then bootstrapped with only a wasm interpreter… and one is provided in a single C file (I believe… but haven’t looked in a while).
This is a much nicer situation than most other bootstrap scenarios. All the SMLs, for instance, require you to have a whole other SML! MoscowML bootstraps with an included Caml interpreter… but it’s not sufficient to compile MLton.
We're not talking about Python 2 here. This is a pre-1.0 language. As an occasional dabbler in the language, I implicitly understand this to mean that there will be breaking changes, and I have made peace with that.
Looking over the changes, they seem wise and well justified. Fixing my old codebases will be annoying, but I don't mind the annoyance if a better language comes out the other end.
> zig team/community has been aggressively marketing this language
...I think the only thing that's aggressively marketed is that the Zig team isn't afraid of big and controversial breaking changes ;) If you can't handle that, then Zig currently isn't right for you, it's as simple as that.
> They could, for example, have versioned stdlib and then maybe all I need to is pin my stdlib version.
That really only makes sense for after 1.0, and even after that only for stdlib APIs that are out of the experimental phase.
But post 1.x some sort of migration support for breaking changes would indeed be much more useful than trying to prevent breaking changes at all cost.
> and I am reminded again why I would never choose this language.
...then why even write such a lengthy comment? Just ignore Zig and move on... it's not like there's plenty of other languages which might better fit your taste.
anyways downloads of older versions are generally available!! like this whole bootstrapping freakout is weird. and anyways its funny to say the wasm build thing is a hack versus building with c. have you seen cmake? that whole thing is a hack.
> with minimal gain
are you sure?