I feel like it's worthless to keep up with Zig until they reach 1.0.
That thing, right here, is probably going to be rewritten 5 times and what not.
If you are actively using Zig (for some reasons?), I guess it's a great news, but for the Grand Majority of the devs in here, it's like an announcement that it's raining in Kuldîga...
So m'yeah. I was following Zig for a while, but I just don't think I am going to see a 1.0 release in my lifetime.
IME Zig's breaking changes are quite manageable for a lot of application types since most of the breakage these days happens in the stdlib and not in the language. And if you just want do read and write files, the highlevel file-io interfaces are nearly identical, they just moved to a different namespace and now require a std.Io pointer to be passed in.
And tbh, I take a 'living' language any day over a language that's ossified because of strict backward compatibility requirements. When updating a 3rd-party dependency to a new major version it's also expected that the code needs to be fixed (except in Zig those breaking changes are in the minor versions, but for 0.x that's also expected).
I actually hope that even after 1.x, Zig will have a strategy to keep the stdlib lean by aggressively removing deprecated interfaces (maybe via separate stdlib interface versions, e.g. `const std = @import("std/v1");`, those versions could be slim compatibility wrappers around a single core stdlib implementation.
> I take a 'living' language any day over of a language that's ossified because of strict backward compatibility requirements
Maybe you would, but >95% of serious projects wouldn't. The typical lifetime of a codebase intended for a lasting application is over 15 or 20 years (in industrial control or aerospace, where low-level languages are commonly used, codebases typically last for over 30 years), and while such changes are manageable early on, they become less so over time.
You say "strict" as if it were out of some kind of stubborn princple, where in fact backward compatibility is one of the things people who write "serious" software want most. Backward compatibility is so popular that at some point it's hard to find any feature that is in high-enough demand to justify breaking it. Even in established languages there's always a group of people who want somethng badly enough they don't mind breaking compatibility for it, but they're almost always a rather small minority. Furthermore, a good record of preserving compatibility in the past makes a language more attractive even for greenfield projects written by people who care about backward compatibility, who, in "serious" software, make up the majority. When you pick a language for such a project, the expectation of how the language will evolve over the next 20 years is a major concern on day one (a startup might not care, but most such software is not written by startups).
> The typical lifetime of a codebase intended for a lasting application is over 15 or 20 years (in industrial control or aerospace).
Either those applications are actively maintained, or they aren't. Part of the active maintenance is to decide whether to upgrade to a new compiler toolchain version (e.g. when in doubt, "never change a running system"), old compiler toolchains won't suddenly stop working.
FWIW, trying to build a 20 or 30 year old C or C++ application in a modern compiler also isn't exactly trivial, depending on the complexity of the code base (especially when there's UB lurking in the code, or the code depends on specific compiler bugs to be present - e.g. changing anything in a project setup always comes with risks attached).
> Part of the active maintenance is to decide whether to upgrade to a new compiler toolchain version
Of course, but you want to make that as easy as you can. Compatibility is never binary (which is why I hate semantic versioning), but you should strive for the greatest compatibility for the greatest portion of users.
> FWIW, trying to build a 20 or 30 year old C or C++ application in a modern compiler also isn't exactly trivial
I know that well (especially for C++; in C the situation is somewhat different), and the backward compatibility of C++ compilers leaves much to be desired.
You could fix versions, and probably should. However willful disregard of prior interfaces encourages developers code to follow suit.
It’s not like Clojure or Common Lisp, where a decades old software still runs, mostly unmodified, the same today, any changes mainly being code written for a different environment or even compiler implementation.
This is largely because they take breaking user code way more seriously. Alot of code written in these languages seem to have similar timelessness too. Software can be “done”.
I would also add that Rust manages this very well. Editions let you do breaking changes without actually breaking any code, since any package (crate) needs to specify the edition it uses. So when in 30 years you're writing code in Rust 2055, you can still import a crate that hasn't been updated since 2015 :)
Unfortunately editions don't allow breaking changes in the standard library, because Rust codes written in different "editions" must be allowed to interoperate freely even within a single build. The resulting constraint is roughly similar to that of never ever breaking ABI in C++.
> The resulting constraint is roughly similar to that of never ever breaking ABI in C++.
No, not even remotely. ABI-stability in C++ means that C++ is stuck with suboptimal implementations of stdlib functions, whereas Rust only stabilizes the exposed interface without stabilizing implementation details.
> Unfortunately editions don't allow breaking changes in the standard library
Surprisingly, this isn't true in practice either. The only thing that Rust needs to guarantee here is that once a specific symbol is exported from the stdlib, that symbol needs to be exported forever. But this still gives an immense amount of flexibility. For example, a new edition could "remove" a deprecated function by completely disallowing any use of a given symbol, while still allowing code on an older edition to access that symbol. Likewise, it's possible to "swap out" a deprecated item for a new item by atomically moving the deprecated item to a new namespace and making the existing item an alias to that new location, then in the new edition you can change the alias to point to the new item instead while leaving the old item accessible (people are exploring this possibility for making non-poisoning mutexes the default in the next edition).
I really love Zig the language, but I'm distancing myself from the stdlib. I dislike the breakage, but I also started questioning the quality of the code recently. I was working on an alternative I/O framework for Zig over the last months, and I was finding many problems that eventually led to me trying to not depend on stdlib at all. Even on the code announced here, the context switching assembly is wrong, it doesn't mark all necessary registers as clobbered. I mentioned this several times to the guys. The fact that it's still unchanged just shows me lack of testing.
It sounds like Zig would benefit from someone like you on the inside, as a member or active contributor, reviewing and participating in the development of the standard library.
Zig is one of my favorite new languages, I really like the cross-compiler too. I'm not a regular user yet but I'm hopeful for its long-term success as a language and ecosystem. It's still early days, beta/dev level instability is expected, and even fundamental changes in design. I think community input and feedback can be particularly valuable at this stage.
I’m confused. The register clobbering is an issue in the compiler, not in the stdlib implementation right? Or are you saying the stdlib has inline assembly in these IO implementations somewhere? I couldn’t find it and I can’t think why you’d need it.
If it’s a compiler frontend-> LLVM interaction bug, I think you are commenting in the spot - it should go in a separate issue not in the PR about io_uring backend. Also, interaction bugs where a compiler frontend triggers a bug in LLVM aren’t uncommon since Rust was the first major frontend other than clang to exercise code paths. Indeed the (your?) fix in LLVM for this issue mentions Rust is impacted too.
I agree with the higher level points about stability and I don’t like Zig not being a safe language in this day and age, but I think your criticism about quality is a bit harsh if your source of this complaint is that they haven’t put a workaround for an LLVM bug.
There is the one issue which I fixed in LLVM, but it should be fixed in Zig as well, because the clobber list in Zig is typed and gives you false impression that adding x30 there is valid. But there is also another issue, x18 is a general purpose register outside of Darwin and Windows and needs to be marked as clobbered on other systems. And yes, look at the linked changes, the stdlib has inline assembly for the context switching.
To each his own, but while I can certainly understand the hesitancy of an architect to pick Zig for a project that is projected to hit 100k+ lines of code, I really think you're missing out. There is a business case to using Zig today.
True in general but in the cloud especially, saving server resources can make a significant impact on the bottom line. There are not nearly enough performance engineers who understand how to take inefficient systems and make improvements to move towards theoretical maximum efficiency. When the system is written in an inefficient language like Python or Node, fundamentally, you have no choice but to start to move the hotpath behind FFI and drop down to a systems language. At that point your choices are basically C, C++, Rust, or Zig. Of the four choices, Zig today is already simplest to learn, with fewer footguns, easier to work with, easier to read and write, and easier to test. And you're not going to write 100k LOC of optimized hotpath code. And when you understand the cost savings involved in reducing your compute needs by sometimes more than 90% by getting the hotpath optimized, you understand that there is very much indeed a business case to learning Zig today.
As a counter argument to this. I was able to replicate the subset of zig that I wanted, using c23. And in the end I have absolute stability unless I break things to “improve”.
Personally, it is a huge pain to rewrite things and update dependencies because the code I am depending on is moving out from under me. I also found this to be a big problem in Rust.
And another huge upside is you have access to best of everything. As an example, I am heavily using fuzz testing and I can very easily use honggfuzz which is the best fuzzer according to all research I could find, and also according to my experience so far.
From this perspective, it doesn’t make sense to use zig over c for professional work. If I am writing a lot of code then I don’t want to rewrite it. If am writing a very small amount of code with no dependencies, then it doesn’t matter what I use and this is the only case where I think zig might make sense.
To add another point to this. W/e people write online isn’t correct all the time. I was thinking zig compiles super fast but found that c with a good build system and well split header/implementation files is basically instant to compile. You can use thin-lto with cache to have instant recompilation for release builds.
Real example: I had to wait some seconds to compile and run benchmarks for a library and it re-compiles instantly (<100ms) with c.
Zig does have a single compilation unit and that might have some advantages but in practice it is a hard disadvantage. And I didn’t ever see someone pointing this out online.
I would really recommend trying to learn c with modernC book and try to do it with c for people like me building something from scratch
Also I was also thinking that breaking doesn’t matter that much, but my opinion changed around 10k lines of code very quickly. At some point I really stopped caring about every piece and wanted to forget about it and move on really
> ...in the cloud especially, saving server resources can make a significant impact on the bottom line. There are not nearly enough performance engineers who understand how to take inefficient systems and make improvements to move towards theoretical maximum efficiency.
That's a very good point, actually. However...
> with fewer footguns
..the Crab People[0] would definitely quibble with that particular claim of yours.
Eh, I'd say that Rust has a different set of footguns. You're correct that you won't run into use-after-free footguns, but Rust doesn't protect you from memory leaks, unsafe code is still unsafe, and the borrow checker and Rust's language complexity are their own kind of footguns.
But I digress. I was thinking of Zig in comparison to C when I wrote that. I don't have a problem conceding that point, but I still believe the overall argument is correct to point to Zig specifically in the case of writing code to optimize a hotpath behind FFI; it is much easier to get to more optimal code and cross-compilation is easier to boot (i.e. to support Darwin/AppleSilicon for dev laptops, and both Linux/x64 and Linux/arm64 for cloud servers).
Ok, but most rust code is not unsafe while all zig code is unsafe.
> and the borrow checker and Rust's language complexity are their own kind of footguns
Please elaborate. They are something to learn but I don’t see the footgun. A footgun is a surprisingly defect that’s pointed at your foot and easy to trigger (ie doing something wrong and your foot blows off). I can’t think how the borrow checker causes that when it’s the exact opposite - you can’t ever create a footgun without doing unsafe because it won’t even compile.
> but I still believe the overall argument is correct to point to Zig specifically in the case of writing code to optimize a hotpath behind FFI; it is much easier to get to more optimal code and cross-compilation is easier to boot (i.e. to support Darwin/AppleSilicon for dev laptops, and both Linux/x64 and Linux/arm64 for cloud servers).
I agree cross compilation with zig is significantly easier but Rust isn’t that hard, especially with the cross-rs crate making it significantly simpler. Performance, Rust is going to be better - zig makes you choose between safety and performance and even in unsafe mode there’s various things that cause better codegen. For example zig follows the C path of manual noalias annotations which has been proven to be non scalable and difficult to make operational. Rust does this for all variables automatically because it’s not allowed in the language.
> a footgun is a surprising defect that's pointed at your foot and easy to trigger
Close, but not the way I think of a footgun. A footgun is code that was written in a naive way, looks correct, submitted, and you find out after submitting it that it was erroneous. Good design makes it easy for people to do the right thing and difficult to do the wrong thing.
In Rust it is extremely easy to hit the borrow checker including for code which is otherwise safe and which you know is safe. You walk on eggshells around the borrow checker hoping that it won't fire and shoot you in the foot and force you to rewrite. It is not a runtime footgun, it is a devtime footgun.
Which, to be fair, is sometimes desired. When you have a 1m+ LOC codebase and dozens of junior engineers working on it and requirements for memory safety and low latency requirements. Fair enough trade-off in that case.
But in Zig, you can just call defer on a deinit function. Complexity is the eternal enemy, and this is just a much simpler approach. The price of that simplicity is that you need to behave like an adult, which if the codebase (hotpath optimization) is <1k LOC I think is eminently reasonable.
> A footgun is code that was written in a naive way, looks correct, submitted, and you find out after submitting it that it was erroneous.
You’re contradicting yourself a bit here I think. Erroneous code generally won’t compile whereas in Zig it will happily do so. Also, Zig has plenty of foot guns (eg forgetting to call defer on a deinit but even misusing noalias or having an out of bounds result in memory corruption). IMHO the zig footgun story with respect to UB behavior is largely unchanged relative to C/C++. It’s mildly better but it’s closer to C/C++ than being a safe language and UB is a huge ass footgun in any moderate complexity codebase.
Depends how you compile it. If you’re compiling ReleaseFast/ReleaseSmall, it’s not very different from C (modulo as you said it has some language features to make it less likely you do it):
* Double free
* Out of bounds array access
* Dereferencing null pointers
* Misaligned pointer dereference
* Accessing uninitialized memory
* Signed integer overflow
* Accessing a union field for which the active tag is something else.
As an example to this, I was using polars in rust as a dependency in a fairly large project.
It has issues like panicking or segfaulting when using some data types (arrow array types) in the wrong place.
It is extremely difficult to write an arrow implementation in Rust.
It is much easier to do it in zig or c(without strict aliasing).
I also had the same experience with glommio in Rust.
Also the binary that we produce compiles in several minutes and is above 30mb. This is an insane amount of bloat. And unfortunately I don’t think there is another feasible way of doing this kind of work in rust, because it is so hard to write proper low level code.
I don’t agree with noalias being bad personally. I fuond it is the only way to do it. It is much harder to write code with pointers with implicit aliasing like c has by default and rust has as the only option. And you don’t ever need to use noalias except some rare places.
To make it clear, I mean the huge footgun in rust is producing a ton of bloat and subpar code because you can’t write much and you end up depending on too many libraries
> To make it clear, I mean the huge footgun in rust is producing a ton of bloat and subpar code because you can’t write much and you end up depending on too many libraries
Nothing is forcing you to do that other than it’s easy to add dependencies. I don’t see how zig is much different
Not the GP, but I've noticed that because if you don't anticipate how you might need to mutate or share state in the future, you can have a "footgun" that forces large-scale code changes for relatively small "feature-level" changes, because of the rust strictness. Its not a footgun in the sense that your code does what you don't expect, its a footgun in that your maintenance and ability to change code is not what you expect (and its easy to do). I'm sure if you are really expert with rust, you see it coming and don't use patterns that will cause waves of changes (but if you're expert at any language you avoid the footguns).
That’s not a footgun and happens in any language. I have not observed rust code to be more prone to it. Certainly less so than c++ for various reasons around the build time and code organization.
>with fewer footguns, easier to work with, easier to read and write, and easier to test.
With the exception of fewer foot guns, which Rust definitely takes the cake and Zig is up in second, I'd say Zig is in last place in all of these. This really screams that you aren't aware of C/C++ testing/tooling ecosystem.
I remember when learning Zig, the documentation for the language itself was extensive, complete, and easily greppable due to being all on one page.
The standard library was a lot less intuitive, but I suspect that has more to do with the amount of churn it's still going through.
The build system also needs more extensive documentation in the same way that the stdlib does, but it has a guide that got me reasonably far with what came out of the box.
I’ll use Ghostty as an example because that’s the only software I use that I know is written in Zig. It’s also a moderately complex project not a toy project.
we (ZML) have been back to following Zig master since std.Io was introduced. It's not that bad tbh. Also most changes really feel like actual improvements to the language on a day to day basis.
I mean, you're right that still so many of us can't use the language yet, but I think we can still applaud progress towards major features when it's less than stable.
Pretty typical jaded HN comment there, chief. "This language's churn is more than I prefer -- why would anyone use it?" If you're not interested, just downvote and move on. Wondering out loud why anyone would actively use it ("for some reasons?") is a lame waste of bytes.
That comment you're complaining about is a useful signal for me who only watches zig from the far periphery. I feel like I'm getting good mileage out of it, just like I do from other, different ones. I'm glad it's in the mix.
LLMs are good at dealing with things they've seen before, not at novel things.
When novel things arise, you will either have to burn a shed ton of tokens on "reasoning", hand hold them (so you're doing advanced find and replace in this example, where you have to be incredibly precise and detailed about your language, to the point it might be quicker to just make the changes), or you have to wait until the next trained model that has seen the new pattern emerges, or quite often, all of the above.
Apologies, but your information is either outdated from lack of experience with the latest frontier models, or you don't realize the fact that 99.9% of the work you do is not novel in all capacities. Have you only used Copilot, or something? Because that's what it sounds like. Since the performance of the latest models (Opus 4.6 max-effort, gpt-5.3-Codex) is nothing short of astonishing.
Real-world example: Claude isn't familiar with the latest Zig, so I had it write a language guide for 0.15.2 (here: https://gist.github.com/pmarreck/44d95e869036027f9edf332ce9a...) which pointed out all the differences, and that's been extremely helpful in having me not even have to touch a line of code to do the updates.
On top of that, for any Zig dependency I pull in which is written to an earlier version, I have forked it and applied these updates correctly (or it has, under my guidance, really), 100% of the time.
On the off chance that guide is not in its context, it has seen the expected warning or error message, googled it, and done the correct correction 100% of the time. Which is exactly what a human would do.
Let's play the falsifiability game: Find me a real-world example of an upgrade to a newer API from the just-previous-to-that API that a modern LLM will fail to do correctly. Your choice of beer or coffee awaits you if you provide a link to it.
Tbh, while impressive that it appears to work, that guide looks very tailored to the Zig stdlib subset used in your projects and also looks like a lot more work than just fixing the errors manually ;) For a large code base which would amortise the cost of this guide I still wouldn't trust the automatic update without carefully reviewing each change.
I’ve been making a project in zig 0.16 with Claude as a learning experiment. It’s a fairly non trivial project (BitTorrent compliant p2p downloader for model weights on top of huggingface xet) - whenever it doesn’t know the syntax or makes errors, it literally reads the standard library code to understand and fix it. The project works too!
Eh, I've had good luck with porting codebases to newer versions of Bevy by pointing CC to the migration guide, and that is harder to test than a language migration (as much of the changed behaviour would have been at runtime).
I still wouldn't want to deal with that much churn in my language, but I fully believe an agent could handle the majority of, if not all of, the migration between versions.
There's a relevant open issue[1] here about stack memory optimization. It would be nice to be able to use a [500]u8 in a block and another [500]u8 in another block, and have that only contribute 500 bytes to the stack frame, but Zig can't currently do this.
(The green threads coro stack stuff makes this more important.)
I don't want to be the negative guy, but this is news about two unfinished implementations. There is a lot of work needed for this to be considered done. For example, no networking in the GCD version yet. And as these are being implemented, the interface stops being an interface, the vtable keeps growing, and it's just the current snapshot of what's needed by the std implementations.
> They are now available to tinker with, by constructing one’s application using std.Io.Evented. They should be considered experimental because there is important followup work to be done before they can be used reliably and robustly:
And then they proceed to list 6 important pending work to be done.
Contrary to the neggies, I am positive in Zigs effort to iterate & improve.
Right now there is no language that is good at io-uring. There are ok offerings, but nothing really has modern async joy that works with uring.
Whoever hammers out a good solution here is going to have a massive leg up. Rust is amazing in so many ways but it has been quite a brutal road to trying to support io-uring ok, and efforts are still a bit primitive, shall we say. If Zig can nail this down that would be fantastic!!
I would way rather Zig keep learning and keep changing, keep making new and better. Than to have it try to appease those who are too conservative for the project, unwilling to accept change and improvement, people focused on stability. It takes a lot of learning to make really good systems, to play with fit and finish. Zig is doing the good work. Imo we ought be thankful.
It’s surprising to me how much people seem to want async in low level languages. Async is very nice in Go, but the reason I reach for a language like Zig is to explicitly control those things. I’m happily writing a Zig project right now using libxev as my io_uring abstraction.
I like Zig, lots of great features that work in unison. However the worry is by the time it reaches v1 Rust will have consumed the space that C/C++ used to. I think it will be a mainstream language though and gain a lot more traction after v1. There is also the issue of will people actually code by then.
I think Rust and Zig really don't overlap much when it comes to target audience. E.g. if you're attracted to Rust, you'll probably find Zig terrible (and the other way around).
Rust will also never replace C or C++ in any meaningful way, at best new code gets written in new languages (and Rust being only one among many, and among languages used for new projects will also be C and C++, just maybe not that often).
I think the era of 'pop star languages' is over, the programming language future is highly diverse (and that's a good thing).
> I think Rust and Zig really don't overlap much when it comes to target audience. E.g. if you're attracted to Rust, you'll probably find Zig terrible (and the other way around).
This is ironic since these two crowds are mostly solving the same type of problems. It's just democrats vs republicans type of split, some of it is just for show and philosophical.
> This is ironic since these two crowds are mostly solving the same type of problems. It's just democrats vs republicans type of split, some of it is just for show and philosophical.
This is a painfully shallow framing.
Yes, programming languages solve problems by emitting instructions that a programmable logic chip can use to preform calculations on input resulting in output. And the scaffolding you use to get there isn't just a matter of philosophical show. Rust as a first order decision will refuse to emit perfectly valid programs because it's unable to prove it's correctness. Zig will emit any program it has enough information to do so. People coding in rust off load much of the effort in understanding and proving that correctness to the compiler. In Zig that relationship is reversed, where the compiler offloads that responsibility to the programmer.
The person you responded to is correct. For some people. Rust solves the difficult and annoying problems, for others it creates difficult and annoying problems.
Some people like creating art, some people like creating software. I guess you could frame that as philosophical, but to call it a political show, belies ignorance to the interactions between systems and predispositions of individuals.
Rust is solving the memory safety problem, Zig is solving the 'idiomatic interop with existing C coding patterns' problem. These couldn't be more different - C-like idiomatic code is generally antithetical to 'safe' modularity since it often relies on tacit global invariants for correct behavior.
Interestingly, Carbon is kinda trying to tackle both at the same time (though starting from C++ in their case) which is a bit of a challenge.
I am not sure how Carbon will go. The Carbon compiler is not ready to be used yet by the public as I understand it, and the roadmap has not been updated for some time now, it seems.
I hear Cardon get mention on rare occasion, and with how rare that is I have to assume it's been completely stagnant. Does it offer anything over C++ in current year? Seems like C++ interop begets turning your language into C++ with different syntax in a way that C interop just doesn't.
The more compelling scenario is one where the unsafe subset of Rust itself becomes roughly as easy to use as Zig is today, though still with potential challenges wrt. properly interacting with safe code.
That requires literally rethinking every language and standard library facility and asking "is this putting up artificial roadblocks or even invoking straight UB when one tries to use it idiomatically in unsafe contexts?", then coming up with more flexible, more "C like" facilities in that case. It's hard work but quite doable.
The roadblock there is a cultural one. Among Rust devs if you ever find the need for an unsafe block then you need an explanation to back it up. If anything, the Rust language would benefit from adding as much friction to unsafe code as possible, so that you're only going to use it when you actually need it.
In other words, the Rust approach to safety is to make as few unsafe LoC as possible, and the Zig approach is to make every unsafe line as safe as possible. As long as their philosophical approach to safety is such that Zig makes writing unsafe code easy and Rust avoids it as much as possible, then writing unsafe code in Zig will always be easier.
The goal of Rust is not so much to avoid unsafe, the goal is to maximize safe code. The reason is that you don't have to check safe code for all the guarantees to get from the Rust language.
This has a big effect on unsafe code. When unsafe code gets called indirectly from safe code, the unsafe code has to make sure that whatever the safe code does, the result is still safe. This requires very careful design of the interface provided by the unsafe code.
I think it is a research question whether Zig would make writing Rust unsafe code a lot easier. In particular the boundary between safe Rust and unsafe code written in Zig could become very tricky. Possibly tricky enough that it would be as complex to write as unsafe Rust today.
The problem is not so much "when unsafe code gets called indirectly by safe code", which is fine if the unsafe happens to be sound. The problem is that "when C-like or Zig-like unsafe code wants to call safe code", the safe code is running in a context where its implied invariants may be violated, leading to insta-UB. Hence code that's intended to provide "library-like" facilities to unsafe blocks cannot be idiomatic Safe Rust, and it needs to be written even more carefully.
For instance, any &mut reference in Rust is assumed not to be aliased, and any &reference not involving UnsafeCell<...> is assumed not to be written to. These implied contracts can be loosened, e.g. by using &Cell<> if applicable (may alias, can be read or written safely, but only "as a whole object": access to the internals does not escape beyond any single operation) which is arguably closer to idiomatic C.
MaybeUninit<> is another common example: C and Zig code often works with possibly-uninitialized data, but this possibility has to be accounted for explicitly in a safe Rust interface. It's always insta-UB if a safe Rust function is passed uninitialized data, even when the equivalent would work idiomatically in C.
This is what makes Rust Rust and I'd say what makes Rust popular. The way safe Rust is safe. Of course this comes at the expense of making writing unsafe a lot harder.
Though I can imagine that unsafe Rust still has to many of the safe Rust's rules. So there could be a better unsafe language that has fewer restrictions.
The real sticking point is not whether there could be a better unsafe language, but a better unsafe library (or unsafe-friendly library that's still conditionally safe in some rigorous sense). That's a much closer goal that could even be achieved within Rust itself as it currently exists today.
No, it's not just a cultural thing. There are very real problems with standard Rust facilities not being accessible/usable from an unsafe context even though the C/C++/Zig idiomatic equivalent would be (i.e. would not invoke instant UB), and these problems are solvable. Sophisticated Rust developers are aware of the issue.
> If anything, the Rust language would benefit from adding as much friction to unsafe code as possible
The friction is there already. I'm not advocating for getting rid of explicit 'unsafe' markings, 'SAFETY' comments or even clunky boilerplate, just for closing a very real gap in capability.
Zig is a drop-in for C. I'm not sure what Rust is but around here no C++ teams seem to be adopting it. Zig on the other hand is seeing adoption in teams who write C for Python binaries. Not a whole lot of it since it's not exactly safe or "stable", but some. Now I'm aware that things like UV are build with Rust, but part of why UV is adopted so widely isn't just that it's fast. It's that it is a drop-in for pip, so that you can compile a requirements.txt and deploy your project without UV, which is handy when you use things like Azure specific Microsoft containers.
Maybe it's just C++ teams being conservative, but a lot of them really seem to hate Rust when you talk with them for whatever reason. I can't imagine why though, but then I've only ever worked with C when I had to, and I have never worked with C++. From having played around with both C++ and Rust, I'd personally pick Rust, but I'm sure it's because I don't know enough. Either way I doubt I'll ever see Rust in a real world job in my corner of the world.
That won't happen if there are legitimate reasons why both Mitchell Hashimoto (creator of Ghostty etc.) and Richard Feldman (of Elm fame, creator of Roc-lang) chose Zig over Rust for their work. They both blogged about it
> the worry is by the time it reaches v1 Rust will have consumed the space that C/C++ used to
Given that Rust is quite an old language now and its adoption is still so low, I don't think that should be much of a worry, although that doesn't mean Zig will be the option of choice, and not stabilising is certainly not a good sign. At Rust's adoption rate, a language that hasn't been invented yet and that would show a more normal rate of adoption for a popular language could easily overtake it.
> There is also the issue of will people actually code by then.
Rust projects generally use licenses like MIT instead of GPL, and thus some major corporations support Rust a lot, and thus Rust will continue getting popular.
> Given that Rust is quite an old language now and its adoption is still so low,
So being part of 3 major OS (Windows, Android and now Linux), the big 3 cloud providers having SDKs for the language, used by so much tooling (js + python) and being part of major internet infrastructure means its “slow” adoption then wow…
Very much so once you compare it to how quickly C++ (and, in fact, any language that's ever been in the top 5 or so) achieved similar milestones. Rust's adoption is very impressive when you compare it to, say, Haskell or Clojure, but not when you compare it to languages that achieved significant and long-lasting popularity. It's roughly similar to Ada's adoption when it was of a similar age (Ada was more prevalent then than Rust is now in some areas and less so in others). When work on Rust started twenty years ago, Java was younger than Rust is now. It was almost as close in time to the early work on C++ as we are now to the early work on Rust. Larger portions of operating systems were being written in C++ when it was younger than Rust is now.
There's no denying Rust's popularity in open-source CLI dev tools for Python and JS/TS, but when you talk to C/C++ shops who've evaluated Rust and see how many of them end up using it (and to what extent) you see it's not like it's been with languages that ended up achieving real popularity (which includes not only super-popular languages like C, C++, and Java, but also mid-popular languages like Go).
> Very much so once you compare it to how quickly C++
C++ came out in 1985 and competed with C, COBOL, Pascal and FORTRAN. It was an overall improvement than those and therefore there is a legit reason for it to take off.
> how many of them end up using it (and to what extent) you see it's not like it's been with languages that ended up achieving real popularity
I assume many places that have a huge codebase in C++ would just do a port to Rust. That would almost always cause problems but for greenfield projects it's a no brainer IMO.
I wouldn’t worry about that. There’s plenty of software yet to be written, in many languages. If anything, Rust’s success has shown that it’s definitely possible for a new language to succeed if it offers something new.
The other tailwind for Zig is that it’s easier than ever to translate an existing codebase with tests into a new language with AI.
I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different.
Zig OTOH is clearly, to me at least (opinion alert), a "better C". It even compiles C!
I expect LLMs to be really good at converting C to Zig.
> There is also the issue of will people actually code by then.
LLMs don't take responsibility. So even if code is generated, a human will have to assess it. I think assessing Zig is easier than assessing C, which gives this language a selling point that holds out in the AI assisted programming future.
I've been coding in Zig for nearly 2 months straight now.
Or should I say, I've not written a single line of Zig because I've been managing AI's coding in Zig.
Turns out Zig is a fantastic language to "centaur" on. (Reference is to "centaur chess" and which is also sort of becoming a term indicating close code design cooperation with an LLM.)
All of that C code that the LLM trained on ends up helping it work out algorithms in Zig, except that Zig has waaaay more safety guarantees and checks. And is often faster compiled code than the equivalent C, which is astonishing.
> I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different.
The same can be said about Zig's comptime. It's entirely unlike anything C, C++ or Rust has to offer.
> I expect LLMs to be really good at converting C to Zig.
While it's possible to translate C to Zig code - and you don't need an LLM for that, it's a Zig compiler/build-system feature - the result will be quite different from a project that's developed in Zig from the ground up since the translation output wouldn't make use of Zig's unique features (and Zig isn't really unique as 'C translation target', C can also be translated to unsafe Rust, or even to Javascript - see early Emscripten versions).
Also, the 'C compatibility' of Zig is implemented via a separate compiler frontend, Rust toolchains could do exactly the same thing by integrating the Clang frontend into the Rust compiler.
Using the same language for compile-time and run-time programming is compelling, but doing it properly requires using the same approaches that dependently typed languages use. Comptime is a bit half baked.
It's not just about writing imperative code that runs at compile time, the actual interesting comptime feature in Zig is that "types are comptime values", e.g. you can inspect types and build new types with regular (comptime) code. This is very different from the template/trait systems in C++ and Rust. What Zig's comptime system is missing is the ability to build functions bodies at comptime (e.g. some sort of comptime AST builder).
I feel like it's worthless to keep up with Zig until they reach 1.0.
That thing, right here, is probably going to be rewritten 5 times and what not.
If you are actively using Zig (for some reasons?), I guess it's a great news, but for the Grand Majority of the devs in here, it's like an announcement that it's raining in Kuldîga...
So m'yeah. I was following Zig for a while, but I just don't think I am going to see a 1.0 release in my lifetime.
IME Zig's breaking changes are quite manageable for a lot of application types since most of the breakage these days happens in the stdlib and not in the language. And if you just want do read and write files, the highlevel file-io interfaces are nearly identical, they just moved to a different namespace and now require a std.Io pointer to be passed in.
And tbh, I take a 'living' language any day over a language that's ossified because of strict backward compatibility requirements. When updating a 3rd-party dependency to a new major version it's also expected that the code needs to be fixed (except in Zig those breaking changes are in the minor versions, but for 0.x that's also expected).
I actually hope that even after 1.x, Zig will have a strategy to keep the stdlib lean by aggressively removing deprecated interfaces (maybe via separate stdlib interface versions, e.g. `const std = @import("std/v1");`, those versions could be slim compatibility wrappers around a single core stdlib implementation.
> I take a 'living' language any day over of a language that's ossified because of strict backward compatibility requirements
Maybe you would, but >95% of serious projects wouldn't. The typical lifetime of a codebase intended for a lasting application is over 15 or 20 years (in industrial control or aerospace, where low-level languages are commonly used, codebases typically last for over 30 years), and while such changes are manageable early on, they become less so over time.
You say "strict" as if it were out of some kind of stubborn princple, where in fact backward compatibility is one of the things people who write "serious" software want most. Backward compatibility is so popular that at some point it's hard to find any feature that is in high-enough demand to justify breaking it. Even in established languages there's always a group of people who want somethng badly enough they don't mind breaking compatibility for it, but they're almost always a rather small minority. Furthermore, a good record of preserving compatibility in the past makes a language more attractive even for greenfield projects written by people who care about backward compatibility, who, in "serious" software, make up the majority. When you pick a language for such a project, the expectation of how the language will evolve over the next 20 years is a major concern on day one (a startup might not care, but most such software is not written by startups).
> The typical lifetime of a codebase intended for a lasting application is over 15 or 20 years (in industrial control or aerospace).
Either those applications are actively maintained, or they aren't. Part of the active maintenance is to decide whether to upgrade to a new compiler toolchain version (e.g. when in doubt, "never change a running system"), old compiler toolchains won't suddenly stop working.
FWIW, trying to build a 20 or 30 year old C or C++ application in a modern compiler also isn't exactly trivial, depending on the complexity of the code base (especially when there's UB lurking in the code, or the code depends on specific compiler bugs to be present - e.g. changing anything in a project setup always comes with risks attached).
> Part of the active maintenance is to decide whether to upgrade to a new compiler toolchain version
Of course, but you want to make that as easy as you can. Compatibility is never binary (which is why I hate semantic versioning), but you should strive for the greatest compatibility for the greatest portion of users.
> FWIW, trying to build a 20 or 30 year old C or C++ application in a modern compiler also isn't exactly trivial
I know that well (especially for C++; in C the situation is somewhat different), and the backward compatibility of C++ compilers leaves much to be desired.
You could fix versions, and probably should. However willful disregard of prior interfaces encourages developers code to follow suit.
It’s not like Clojure or Common Lisp, where a decades old software still runs, mostly unmodified, the same today, any changes mainly being code written for a different environment or even compiler implementation. This is largely because they take breaking user code way more seriously. Alot of code written in these languages seem to have similar timelessness too. Software can be “done”.
I would also add that Rust manages this very well. Editions let you do breaking changes without actually breaking any code, since any package (crate) needs to specify the edition it uses. So when in 30 years you're writing code in Rust 2055, you can still import a crate that hasn't been updated since 2015 :)
Unfortunately editions don't allow breaking changes in the standard library, because Rust codes written in different "editions" must be allowed to interoperate freely even within a single build. The resulting constraint is roughly similar to that of never ever breaking ABI in C++.
> The resulting constraint is roughly similar to that of never ever breaking ABI in C++.
No, not even remotely. ABI-stability in C++ means that C++ is stuck with suboptimal implementations of stdlib functions, whereas Rust only stabilizes the exposed interface without stabilizing implementation details.
> Unfortunately editions don't allow breaking changes in the standard library
Surprisingly, this isn't true in practice either. The only thing that Rust needs to guarantee here is that once a specific symbol is exported from the stdlib, that symbol needs to be exported forever. But this still gives an immense amount of flexibility. For example, a new edition could "remove" a deprecated function by completely disallowing any use of a given symbol, while still allowing code on an older edition to access that symbol. Likewise, it's possible to "swap out" a deprecated item for a new item by atomically moving the deprecated item to a new namespace and making the existing item an alias to that new location, then in the new edition you can change the alias to point to the new item instead while leaving the old item accessible (people are exploring this possibility for making non-poisoning mutexes the default in the next edition).
I really love Zig the language, but I'm distancing myself from the stdlib. I dislike the breakage, but I also started questioning the quality of the code recently. I was working on an alternative I/O framework for Zig over the last months, and I was finding many problems that eventually led to me trying to not depend on stdlib at all. Even on the code announced here, the context switching assembly is wrong, it doesn't mark all necessary registers as clobbered. I mentioned this several times to the guys. The fact that it's still unchanged just shows me lack of testing.
It sounds like Zig would benefit from someone like you on the inside, as a member or active contributor, reviewing and participating in the development of the standard library.
Zig is one of my favorite new languages, I really like the cross-compiler too. I'm not a regular user yet but I'm hopeful for its long-term success as a language and ecosystem. It's still early days, beta/dev level instability is expected, and even fundamental changes in design. I think community input and feedback can be particularly valuable at this stage.
I dont think the core team accepts LLM generated code in the std.
I’m confused. The register clobbering is an issue in the compiler, not in the stdlib implementation right? Or are you saying the stdlib has inline assembly in these IO implementations somewhere? I couldn’t find it and I can’t think why you’d need it.
If it’s a compiler frontend-> LLVM interaction bug, I think you are commenting in the spot - it should go in a separate issue not in the PR about io_uring backend. Also, interaction bugs where a compiler frontend triggers a bug in LLVM aren’t uncommon since Rust was the first major frontend other than clang to exercise code paths. Indeed the (your?) fix in LLVM for this issue mentions Rust is impacted too.
I agree with the higher level points about stability and I don’t like Zig not being a safe language in this day and age, but I think your criticism about quality is a bit harsh if your source of this complaint is that they haven’t put a workaround for an LLVM bug.
There is the one issue which I fixed in LLVM, but it should be fixed in Zig as well, because the clobber list in Zig is typed and gives you false impression that adding x30 there is valid. But there is also another issue, x18 is a general purpose register outside of Darwin and Windows and needs to be marked as clobbered on other systems. And yes, look at the linked changes, the stdlib has inline assembly for the context switching.
To each his own, but while I can certainly understand the hesitancy of an architect to pick Zig for a project that is projected to hit 100k+ lines of code, I really think you're missing out. There is a business case to using Zig today.
True in general but in the cloud especially, saving server resources can make a significant impact on the bottom line. There are not nearly enough performance engineers who understand how to take inefficient systems and make improvements to move towards theoretical maximum efficiency. When the system is written in an inefficient language like Python or Node, fundamentally, you have no choice but to start to move the hotpath behind FFI and drop down to a systems language. At that point your choices are basically C, C++, Rust, or Zig. Of the four choices, Zig today is already simplest to learn, with fewer footguns, easier to work with, easier to read and write, and easier to test. And you're not going to write 100k LOC of optimized hotpath code. And when you understand the cost savings involved in reducing your compute needs by sometimes more than 90% by getting the hotpath optimized, you understand that there is very much indeed a business case to learning Zig today.
As a counter argument to this. I was able to replicate the subset of zig that I wanted, using c23. And in the end I have absolute stability unless I break things to “improve”.
Personally, it is a huge pain to rewrite things and update dependencies because the code I am depending on is moving out from under me. I also found this to be a big problem in Rust.
And another huge upside is you have access to best of everything. As an example, I am heavily using fuzz testing and I can very easily use honggfuzz which is the best fuzzer according to all research I could find, and also according to my experience so far.
From this perspective, it doesn’t make sense to use zig over c for professional work. If I am writing a lot of code then I don’t want to rewrite it. If am writing a very small amount of code with no dependencies, then it doesn’t matter what I use and this is the only case where I think zig might make sense.
To add another point to this. W/e people write online isn’t correct all the time. I was thinking zig compiles super fast but found that c with a good build system and well split header/implementation files is basically instant to compile. You can use thin-lto with cache to have instant recompilation for release builds.
Real example: I had to wait some seconds to compile and run benchmarks for a library and it re-compiles instantly (<100ms) with c.
Zig does have a single compilation unit and that might have some advantages but in practice it is a hard disadvantage. And I didn’t ever see someone pointing this out online.
I would really recommend trying to learn c with modernC book and try to do it with c for people like me building something from scratch
Also I was also thinking that breaking doesn’t matter that much, but my opinion changed around 10k lines of code very quickly. At some point I really stopped caring about every piece and wanted to forget about it and move on really
> ...in the cloud especially, saving server resources can make a significant impact on the bottom line. There are not nearly enough performance engineers who understand how to take inefficient systems and make improvements to move towards theoretical maximum efficiency.
That's a very good point, actually. However...
> with fewer footguns
..the Crab People[0] would definitely quibble with that particular claim of yours.
[0] https://en.wikipedia.org/wiki/Crab_People of course.
I would quibble with all of the claims, other than easier to learn.
I really see no advantage for Zig over Rust after you get past that 2 first two weeks.
Eh, I'd say that Rust has a different set of footguns. You're correct that you won't run into use-after-free footguns, but Rust doesn't protect you from memory leaks, unsafe code is still unsafe, and the borrow checker and Rust's language complexity are their own kind of footguns.
But I digress. I was thinking of Zig in comparison to C when I wrote that. I don't have a problem conceding that point, but I still believe the overall argument is correct to point to Zig specifically in the case of writing code to optimize a hotpath behind FFI; it is much easier to get to more optimal code and cross-compilation is easier to boot (i.e. to support Darwin/AppleSilicon for dev laptops, and both Linux/x64 and Linux/arm64 for cloud servers).
> but Rust doesn't protect you from memory leaks
In theory no. In practice it really does.
> unsafe code is still unsafe
Ok, but most rust code is not unsafe while all zig code is unsafe.
> and the borrow checker and Rust's language complexity are their own kind of footguns
Please elaborate. They are something to learn but I don’t see the footgun. A footgun is a surprisingly defect that’s pointed at your foot and easy to trigger (ie doing something wrong and your foot blows off). I can’t think how the borrow checker causes that when it’s the exact opposite - you can’t ever create a footgun without doing unsafe because it won’t even compile.
> but I still believe the overall argument is correct to point to Zig specifically in the case of writing code to optimize a hotpath behind FFI; it is much easier to get to more optimal code and cross-compilation is easier to boot (i.e. to support Darwin/AppleSilicon for dev laptops, and both Linux/x64 and Linux/arm64 for cloud servers).
I agree cross compilation with zig is significantly easier but Rust isn’t that hard, especially with the cross-rs crate making it significantly simpler. Performance, Rust is going to be better - zig makes you choose between safety and performance and even in unsafe mode there’s various things that cause better codegen. For example zig follows the C path of manual noalias annotations which has been proven to be non scalable and difficult to make operational. Rust does this for all variables automatically because it’s not allowed in the language.
> a footgun is a surprising defect that's pointed at your foot and easy to trigger
Close, but not the way I think of a footgun. A footgun is code that was written in a naive way, looks correct, submitted, and you find out after submitting it that it was erroneous. Good design makes it easy for people to do the right thing and difficult to do the wrong thing.
In Rust it is extremely easy to hit the borrow checker including for code which is otherwise safe and which you know is safe. You walk on eggshells around the borrow checker hoping that it won't fire and shoot you in the foot and force you to rewrite. It is not a runtime footgun, it is a devtime footgun.
Which, to be fair, is sometimes desired. When you have a 1m+ LOC codebase and dozens of junior engineers working on it and requirements for memory safety and low latency requirements. Fair enough trade-off in that case.
But in Zig, you can just call defer on a deinit function. Complexity is the eternal enemy, and this is just a much simpler approach. The price of that simplicity is that you need to behave like an adult, which if the codebase (hotpath optimization) is <1k LOC I think is eminently reasonable.
> A footgun is code that was written in a naive way, looks correct, submitted, and you find out after submitting it that it was erroneous.
You’re contradicting yourself a bit here I think. Erroneous code generally won’t compile whereas in Zig it will happily do so. Also, Zig has plenty of foot guns (eg forgetting to call defer on a deinit but even misusing noalias or having an out of bounds result in memory corruption). IMHO the zig footgun story with respect to UB behavior is largely unchanged relative to C/C++. It’s mildly better but it’s closer to C/C++ than being a safe language and UB is a huge ass footgun in any moderate complexity codebase.
> IMHO the zig footgun story with respect to UB behavior is largely unchanged relative to C/C++
The only major UB from C that zig doesn’t address is use after free afaik. How is that largely unchanged???
Just having an actual strong type system w/o the “billion dollar mistake” is a large change.
Depends how you compile it. If you’re compiling ReleaseFast/ReleaseSmall, it’s not very different from C (modulo as you said it has some language features to make it less likely you do it):
* Double free
* Out of bounds array access
* Dereferencing null pointers
* Misaligned pointer dereference
* Accessing uninitialized memory
* Signed integer overflow
* Accessing a union field for which the active tag is something else.
As an example to this, I was using polars in rust as a dependency in a fairly large project.
It has issues like panicking or segfaulting when using some data types (arrow array types) in the wrong place.
It is extremely difficult to write an arrow implementation in Rust.
It is much easier to do it in zig or c(without strict aliasing).
I also had the same experience with glommio in Rust.
Also the binary that we produce compiles in several minutes and is above 30mb. This is an insane amount of bloat. And unfortunately I don’t think there is another feasible way of doing this kind of work in rust, because it is so hard to write proper low level code.
I don’t agree with noalias being bad personally. I fuond it is the only way to do it. It is much harder to write code with pointers with implicit aliasing like c has by default and rust has as the only option. And you don’t ever need to use noalias except some rare places.
To make it clear, I mean the huge footgun in rust is producing a ton of bloat and subpar code because you can’t write much and you end up depending on too many libraries
> To make it clear, I mean the huge footgun in rust is producing a ton of bloat and subpar code because you can’t write much and you end up depending on too many libraries
Nothing is forcing you to do that other than it’s easy to add dependencies. I don’t see how zig is much different
Not the GP, but I've noticed that because if you don't anticipate how you might need to mutate or share state in the future, you can have a "footgun" that forces large-scale code changes for relatively small "feature-level" changes, because of the rust strictness. Its not a footgun in the sense that your code does what you don't expect, its a footgun in that your maintenance and ability to change code is not what you expect (and its easy to do). I'm sure if you are really expert with rust, you see it coming and don't use patterns that will cause waves of changes (but if you're expert at any language you avoid the footguns).
That’s not a footgun and happens in any language. I have not observed rust code to be more prone to it. Certainly less so than c++ for various reasons around the build time and code organization.
>with fewer footguns, easier to work with, easier to read and write, and easier to test.
With the exception of fewer foot guns, which Rust definitely takes the cake and Zig is up in second, I'd say Zig is in last place in all of these. This really screams that you aren't aware of C/C++ testing/tooling ecosystem.
I say this as a fan of Zig, by the way.
> Of the four choices, Zig today is already simplest to learn,
Yes, with almost complete lack of documentation and learning materials it is definitely the easiest language to learn.
For reference, here's where Zig's documentation lives:
https://ziglang.org/learn/
I remember when learning Zig, the documentation for the language itself was extensive, complete, and easily greppable due to being all on one page.
The standard library was a lot less intuitive, but I suspect that has more to do with the amount of churn it's still going through.
The build system also needs more extensive documentation in the same way that the stdlib does, but it has a guide that got me reasonably far with what came out of the box.
For what it's worth, Bun is written in Zig (https://bun.sh/). The language isn't exactly in an early stage.
Oh but it is.
Oh but it isn’t.
They just did a massive reactor that broke nearly 100% of existing code. Only an early language can do that.
What version are you referring to? I've had zero issues updating my zig stuff to 0.15.2 with frontier LLM assistance.
0.16 changes things around dramatically.
I’ll use Ghostty as an example because that’s the only software I use that I know is written in Zig. It’s also a moderately complex project not a toy project.
Its Zig 0.15 effort started in August and was only complete in October (see first PR at https://github.com/ghostty-org/ghostty/pull/8372). And many issues were encountered and solved along the way. And of course during all of this they also encountered an issue in Zig itself: https://github.com/ziglang/zig/issues/24627
The huge change that will be passing Io objects around like you have with Allocator.
Please stop posting 0-information-content complaints.
we (ZML) have been back to following Zig master since std.Io was introduced. It's not that bad tbh. Also most changes really feel like actual improvements to the language on a day to day basis.
You're assuming that 1.0 will bring about stability. For all we know version 1.0 could make way for version 2.0 soon after.
Though perhaps the Zig developers have promised this will not happen.
No shame in waiting for 1.0. Specially if you want to read docs rather than the code itself.
Akctuyally, reading the code instead of a documentation is one of the nice part of Zig.
It is such a readable language that I found it easier learning the API than most languages.
Zig has this on its side. Reading the unit tests directly from the code give, most of the time, a good example too.
> but for the Grand Majority of the devs in here, it's like an announcement that it's raining in Kuldîga...
Lol, I’ll borrow this.
I wouldn't have expected graphic sex slang to be acceptable as a NH user name.
This would translate as ~"eats pussy", where "broûter" is a verb reserved for animals feeding on grass, implying a hefty bush.
I mean, you're right that still so many of us can't use the language yet, but I think we can still applaud progress towards major features when it's less than stable.
Kudos Zig contributors!
Pretty typical jaded HN comment there, chief. "This language's churn is more than I prefer -- why would anyone use it?" If you're not interested, just downvote and move on. Wondering out loud why anyone would actively use it ("for some reasons?") is a lame waste of bytes.
That comment you're complaining about is a useful signal for me who only watches zig from the far periphery. I feel like I'm getting good mileage out of it, just like I do from other, different ones. I'm glad it's in the mix.
An AI will be able to handle updating your code for 95% of your breaking changes
No it won't.
LLMs are good at dealing with things they've seen before, not at novel things.
When novel things arise, you will either have to burn a shed ton of tokens on "reasoning", hand hold them (so you're doing advanced find and replace in this example, where you have to be incredibly precise and detailed about your language, to the point it might be quicker to just make the changes), or you have to wait until the next trained model that has seen the new pattern emerges, or quite often, all of the above.
Apologies, but your information is either outdated from lack of experience with the latest frontier models, or you don't realize the fact that 99.9% of the work you do is not novel in all capacities. Have you only used Copilot, or something? Because that's what it sounds like. Since the performance of the latest models (Opus 4.6 max-effort, gpt-5.3-Codex) is nothing short of astonishing.
Real-world example: Claude isn't familiar with the latest Zig, so I had it write a language guide for 0.15.2 (here: https://gist.github.com/pmarreck/44d95e869036027f9edf332ce9a...) which pointed out all the differences, and that's been extremely helpful in having me not even have to touch a line of code to do the updates.
On top of that, for any Zig dependency I pull in which is written to an earlier version, I have forked it and applied these updates correctly (or it has, under my guidance, really), 100% of the time.
On the off chance that guide is not in its context, it has seen the expected warning or error message, googled it, and done the correct correction 100% of the time. Which is exactly what a human would do.
Let's play the falsifiability game: Find me a real-world example of an upgrade to a newer API from the just-previous-to-that API that a modern LLM will fail to do correctly. Your choice of beer or coffee awaits you if you provide a link to it.
> so I had it write a language guide for 0.15.2
Tbh, while impressive that it appears to work, that guide looks very tailored to the Zig stdlib subset used in your projects and also looks like a lot more work than just fixing the errors manually ;) For a large code base which would amortise the cost of this guide I still wouldn't trust the automatic update without carefully reviewing each change.
I’ve been making a project in zig 0.16 with Claude as a learning experiment. It’s a fairly non trivial project (BitTorrent compliant p2p downloader for model weights on top of huggingface xet) - whenever it doesn’t know the syntax or makes errors, it literally reads the standard library code to understand and fix it. The project works too!
Just have to wait a few months until a new model with updated pretrained knowledge comes out.
Or spend those few months doing the update :-)
Eh, I've had good luck with porting codebases to newer versions of Bevy by pointing CC to the migration guide, and that is harder to test than a language migration (as much of the changed behaviour would have been at runtime).
I still wouldn't want to deal with that much churn in my language, but I fully believe an agent could handle the majority of, if not all of, the migration between versions.
There's a relevant open issue[1] here about stack memory optimization. It would be nice to be able to use a [500]u8 in a block and another [500]u8 in another block, and have that only contribute 500 bytes to the stack frame, but Zig can't currently do this.
(The green threads coro stack stuff makes this more important.)
[1]: https://github.com/ziglang/zig/issues/23475#issuecomment-279...
I don't want to be the negative guy, but this is news about two unfinished implementations. There is a lot of work needed for this to be considered done. For example, no networking in the GCD version yet. And as these are being implemented, the interface stops being an interface, the vtable keeps growing, and it's just the current snapshot of what's needed by the std implementations.
They aknowlege that at the beggining of the post?
> They are now available to tinker with, by constructing one’s application using std.Io.Evented. They should be considered experimental because there is important followup work to be done before they can be used reliably and robustly:
And then they proceed to list 6 important pending work to be done.
It doesn't say "minor" details like networking not being implemented :)
Contrary to the neggies, I am positive in Zigs effort to iterate & improve.
Right now there is no language that is good at io-uring. There are ok offerings, but nothing really has modern async joy that works with uring.
Whoever hammers out a good solution here is going to have a massive leg up. Rust is amazing in so many ways but it has been quite a brutal road to trying to support io-uring ok, and efforts are still a bit primitive, shall we say. If Zig can nail this down that would be fantastic!!
I would way rather Zig keep learning and keep changing, keep making new and better. Than to have it try to appease those who are too conservative for the project, unwilling to accept change and improvement, people focused on stability. It takes a lot of learning to make really good systems, to play with fit and finish. Zig is doing the good work. Imo we ought be thankful.
It’s surprising to me how much people seem to want async in low level languages. Async is very nice in Go, but the reason I reach for a language like Zig is to explicitly control those things. I’m happily writing a Zig project right now using libxev as my io_uring abstraction.
But Zig's async is being designed to enable this low-level control.
I like that zig takes freestanding target seriously. And seems like 0.16 becomes even better for freestanding code reusability.
I’m waiting for the kqueue implementation.
Haven’t looked into MacOS internals for a while, happy to see they stuck to GCD, great middle ground for parallelisation
When a language starts to do this kind of thing, you know it isn’t going to replace C.
> Both of these are based on userspace stack switching, sometimes called “fibers”, “stackful coroutines”, or “green threads”.
I like Zig, lots of great features that work in unison. However the worry is by the time it reaches v1 Rust will have consumed the space that C/C++ used to. I think it will be a mainstream language though and gain a lot more traction after v1. There is also the issue of will people actually code by then.
I think Rust and Zig really don't overlap much when it comes to target audience. E.g. if you're attracted to Rust, you'll probably find Zig terrible (and the other way around).
Rust will also never replace C or C++ in any meaningful way, at best new code gets written in new languages (and Rust being only one among many, and among languages used for new projects will also be C and C++, just maybe not that often).
I think the era of 'pop star languages' is over, the programming language future is highly diverse (and that's a good thing).
> Rust will also never replace C or C++ in any meaningful way
Not only do I disagree it never will, I think it's already well on its way to doing exactly that.
> I think Rust and Zig really don't overlap much when it comes to target audience. E.g. if you're attracted to Rust, you'll probably find Zig terrible (and the other way around).
This is ironic since these two crowds are mostly solving the same type of problems. It's just democrats vs republicans type of split, some of it is just for show and philosophical.
> This is ironic since these two crowds are mostly solving the same type of problems. It's just democrats vs republicans type of split, some of it is just for show and philosophical.
This is a painfully shallow framing.
Yes, programming languages solve problems by emitting instructions that a programmable logic chip can use to preform calculations on input resulting in output. And the scaffolding you use to get there isn't just a matter of philosophical show. Rust as a first order decision will refuse to emit perfectly valid programs because it's unable to prove it's correctness. Zig will emit any program it has enough information to do so. People coding in rust off load much of the effort in understanding and proving that correctness to the compiler. In Zig that relationship is reversed, where the compiler offloads that responsibility to the programmer.
The person you responded to is correct. For some people. Rust solves the difficult and annoying problems, for others it creates difficult and annoying problems.
Some people like creating art, some people like creating software. I guess you could frame that as philosophical, but to call it a political show, belies ignorance to the interactions between systems and predispositions of individuals.
Rust is solving the memory safety problem, Zig is solving the 'idiomatic interop with existing C coding patterns' problem. These couldn't be more different - C-like idiomatic code is generally antithetical to 'safe' modularity since it often relies on tacit global invariants for correct behavior.
Interestingly, Carbon is kinda trying to tackle both at the same time (though starting from C++ in their case) which is a bit of a challenge.
I was more referring to the type of things 90% of the developers are likely to build. In most cases that'll be command line tools, libraries or API's.
I am not sure how Carbon will go. The Carbon compiler is not ready to be used yet by the public as I understand it, and the roadmap has not been updated for some time now, it seems.
https://docs.carbon-lang.dev/docs/project/roadmap.html
I hear Cardon get mention on rare occasion, and with how rare that is I have to assume it's been completely stagnant. Does it offer anything over C++ in current year? Seems like C++ interop begets turning your language into C++ with different syntax in a way that C interop just doesn't.
The GitHub project has some activity at least, and they might be coming with some announcement later this year.
https://github.com/carbon-language/carbon-lang/
The more compelling scenario is one where the unsafe subset of Rust itself becomes roughly as easy to use as Zig is today, though still with potential challenges wrt. properly interacting with safe code.
That requires literally rethinking every language and standard library facility and asking "is this putting up artificial roadblocks or even invoking straight UB when one tries to use it idiomatically in unsafe contexts?", then coming up with more flexible, more "C like" facilities in that case. It's hard work but quite doable.
The roadblock there is a cultural one. Among Rust devs if you ever find the need for an unsafe block then you need an explanation to back it up. If anything, the Rust language would benefit from adding as much friction to unsafe code as possible, so that you're only going to use it when you actually need it.
In other words, the Rust approach to safety is to make as few unsafe LoC as possible, and the Zig approach is to make every unsafe line as safe as possible. As long as their philosophical approach to safety is such that Zig makes writing unsafe code easy and Rust avoids it as much as possible, then writing unsafe code in Zig will always be easier.
The goal of Rust is not so much to avoid unsafe, the goal is to maximize safe code. The reason is that you don't have to check safe code for all the guarantees to get from the Rust language.
This has a big effect on unsafe code. When unsafe code gets called indirectly from safe code, the unsafe code has to make sure that whatever the safe code does, the result is still safe. This requires very careful design of the interface provided by the unsafe code.
I think it is a research question whether Zig would make writing Rust unsafe code a lot easier. In particular the boundary between safe Rust and unsafe code written in Zig could become very tricky. Possibly tricky enough that it would be as complex to write as unsafe Rust today.
The problem is not so much "when unsafe code gets called indirectly by safe code", which is fine if the unsafe happens to be sound. The problem is that "when C-like or Zig-like unsafe code wants to call safe code", the safe code is running in a context where its implied invariants may be violated, leading to insta-UB. Hence code that's intended to provide "library-like" facilities to unsafe blocks cannot be idiomatic Safe Rust, and it needs to be written even more carefully.
For instance, any &mut reference in Rust is assumed not to be aliased, and any &reference not involving UnsafeCell<...> is assumed not to be written to. These implied contracts can be loosened, e.g. by using &Cell<> if applicable (may alias, can be read or written safely, but only "as a whole object": access to the internals does not escape beyond any single operation) which is arguably closer to idiomatic C.
MaybeUninit<> is another common example: C and Zig code often works with possibly-uninitialized data, but this possibility has to be accounted for explicitly in a safe Rust interface. It's always insta-UB if a safe Rust function is passed uninitialized data, even when the equivalent would work idiomatically in C.
This is what makes Rust Rust and I'd say what makes Rust popular. The way safe Rust is safe. Of course this comes at the expense of making writing unsafe a lot harder.
Though I can imagine that unsafe Rust still has to many of the safe Rust's rules. So there could be a better unsafe language that has fewer restrictions.
The real sticking point is not whether there could be a better unsafe language, but a better unsafe library (or unsafe-friendly library that's still conditionally safe in some rigorous sense). That's a much closer goal that could even be achieved within Rust itself as it currently exists today.
No, it's not just a cultural thing. There are very real problems with standard Rust facilities not being accessible/usable from an unsafe context even though the C/C++/Zig idiomatic equivalent would be (i.e. would not invoke instant UB), and these problems are solvable. Sophisticated Rust developers are aware of the issue.
> If anything, the Rust language would benefit from adding as much friction to unsafe code as possible
The friction is there already. I'm not advocating for getting rid of explicit 'unsafe' markings, 'SAFETY' comments or even clunky boilerplate, just for closing a very real gap in capability.
Zig is a drop-in for C. I'm not sure what Rust is but around here no C++ teams seem to be adopting it. Zig on the other hand is seeing adoption in teams who write C for Python binaries. Not a whole lot of it since it's not exactly safe or "stable", but some. Now I'm aware that things like UV are build with Rust, but part of why UV is adopted so widely isn't just that it's fast. It's that it is a drop-in for pip, so that you can compile a requirements.txt and deploy your project without UV, which is handy when you use things like Azure specific Microsoft containers.
Maybe it's just C++ teams being conservative, but a lot of them really seem to hate Rust when you talk with them for whatever reason. I can't imagine why though, but then I've only ever worked with C when I had to, and I have never worked with C++. From having played around with both C++ and Rust, I'd personally pick Rust, but I'm sure it's because I don't know enough. Either way I doubt I'll ever see Rust in a real world job in my corner of the world.
That won't happen if there are legitimate reasons why both Mitchell Hashimoto (creator of Ghostty etc.) and Richard Feldman (of Elm fame, creator of Roc-lang) chose Zig over Rust for their work. They both blogged about it
https://tomas-svojanovsky.medium.com/mitchell-hashimoto-go-a...
https://www.youtube.com/watch?v=dJ5-41u-e7k
https://weeklyrust.substack.com/p/why-roc-is-moving-away-fro...
Perhaps there is room for both... via C FFI interop, of course, lol
(C FFI will probably long outlast C itself...)
> why both Mitchell Hashimoto (creator of Ghostty etc.) and Richard Feldman (of Elm fame, creator of Roc-lang)
Both undoubtedly are talented programmers, but you overestimate impact and importance of these project.
GitHub stars and HN posts are not very good indicator of what happens in the real world
> the worry is by the time it reaches v1 Rust will have consumed the space that C/C++ used to
Given that Rust is quite an old language now and its adoption is still so low, I don't think that should be much of a worry, although that doesn't mean Zig will be the option of choice, and not stabilising is certainly not a good sign. At Rust's adoption rate, a language that hasn't been invented yet and that would show a more normal rate of adoption for a popular language could easily overtake it.
> There is also the issue of will people actually code by then.
Now that could be a bigger issue. :)
Rust projects generally use licenses like MIT instead of GPL, and thus some major corporations support Rust a lot, and thus Rust will continue getting popular.
> Given that Rust is quite an old language now and its adoption is still so low,
So being part of 3 major OS (Windows, Android and now Linux), the big 3 cloud providers having SDKs for the language, used by so much tooling (js + python) and being part of major internet infrastructure means its “slow” adoption then wow…
Very much so once you compare it to how quickly C++ (and, in fact, any language that's ever been in the top 5 or so) achieved similar milestones. Rust's adoption is very impressive when you compare it to, say, Haskell or Clojure, but not when you compare it to languages that achieved significant and long-lasting popularity. It's roughly similar to Ada's adoption when it was of a similar age (Ada was more prevalent then than Rust is now in some areas and less so in others). When work on Rust started twenty years ago, Java was younger than Rust is now. It was almost as close in time to the early work on C++ as we are now to the early work on Rust. Larger portions of operating systems were being written in C++ when it was younger than Rust is now.
There's no denying Rust's popularity in open-source CLI dev tools for Python and JS/TS, but when you talk to C/C++ shops who've evaluated Rust and see how many of them end up using it (and to what extent) you see it's not like it's been with languages that ended up achieving real popularity (which includes not only super-popular languages like C, C++, and Java, but also mid-popular languages like Go).
> Very much so once you compare it to how quickly C++
C++ came out in 1985 and competed with C, COBOL, Pascal and FORTRAN. It was an overall improvement than those and therefore there is a legit reason for it to take off.
> how many of them end up using it (and to what extent) you see it's not like it's been with languages that ended up achieving real popularity
I assume many places that have a huge codebase in C++ would just do a port to Rust. That would almost always cause problems but for greenfield projects it's a no brainer IMO.
I wouldn’t worry about that. There’s plenty of software yet to be written, in many languages. If anything, Rust’s success has shown that it’s definitely possible for a new language to succeed if it offers something new.
The other tailwind for Zig is that it’s easier than ever to translate an existing codebase with tests into a new language with AI.
I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different.
Zig OTOH is clearly, to me at least (opinion alert), a "better C". It even compiles C!
I expect LLMs to be really good at converting C to Zig.
> There is also the issue of will people actually code by then.
LLMs don't take responsibility. So even if code is generated, a human will have to assess it. I think assessing Zig is easier than assessing C, which gives this language a selling point that holds out in the AI assisted programming future.
I've been coding in Zig for nearly 2 months straight now.
Or should I say, I've not written a single line of Zig because I've been managing AI's coding in Zig.
Turns out Zig is a fantastic language to "centaur" on. (Reference is to "centaur chess" and which is also sort of becoming a term indicating close code design cooperation with an LLM.)
All of that C code that the LLM trained on ends up helping it work out algorithms in Zig, except that Zig has waaaay more safety guarantees and checks. And is often faster compiled code than the equivalent C, which is astonishing.
I like that I can easily smell bad Zig by looking at it, but I'm notoriously bad at smelling bad C.
> I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different.
The same can be said about Zig's comptime. It's entirely unlike anything C, C++ or Rust has to offer.
> I expect LLMs to be really good at converting C to Zig.
While it's possible to translate C to Zig code - and you don't need an LLM for that, it's a Zig compiler/build-system feature - the result will be quite different from a project that's developed in Zig from the ground up since the translation output wouldn't make use of Zig's unique features (and Zig isn't really unique as 'C translation target', C can also be translated to unsafe Rust, or even to Javascript - see early Emscripten versions).
Also, the 'C compatibility' of Zig is implemented via a separate compiler frontend, Rust toolchains could do exactly the same thing by integrating the Clang frontend into the Rust compiler.
Using the same language for compile-time and run-time programming is compelling, but doing it properly requires using the same approaches that dependently typed languages use. Comptime is a bit half baked.
It's not just about writing imperative code that runs at compile time, the actual interesting comptime feature in Zig is that "types are comptime values", e.g. you can inspect types and build new types with regular (comptime) code. This is very different from the template/trait systems in C++ and Rust. What Zig's comptime system is missing is the ability to build functions bodies at comptime (e.g. some sort of comptime AST builder).
"You can inspect types and build new types at compile time" is a key affordance of dependently typed languages.
Zig's comptime is an addition. You don't have to use it. And some C-macros may translate quite cleanly to it.
OTOH going from C++ (OO) to Rust (not OO, borrow checker) is a big leap.