alt.hn

2/14/2026 at 8:22:11 AM

Zig – io_uring and Grand Central Dispatch std.Io implementations landed

 https://ziglang.org/devlog/2026/#2026-02-13

by Retro_Dev

2/14/2026 at 11:39:48 AM

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.

by jauntywundrkind

2/14/2026 at 1:26:34 PM

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.

by hxtk

2/14/2026 at 6:22:28 PM

Using async in low level languages goes all the way back to the 1960's, became common in systems languages like Solo Pascal, Modula-2, with Dr.Dobbs and The C/C++ User's Journal having plenty of articles regarding C extensions for similar purposes.

Hardly anything radical.

by pjmlp

2/14/2026 at 7:01:04 PM

When I look at historical cases, it seems different from a case today. If I’m a programmer in the 60s wanting async in my “low level language,” what I actually want is to make some of the highest level languages available at the time even more high level in their IO abstractions. As I understand it, C was a high-level language when it was invented, as opposed to assembly with macros. People wanting to add async were extending the state of the art for high level abstraction.

A language doing it today is doing it in the context of an ecosystem where even higher level languages exist and they have made the choice to target a lower level of abstraction.

by hxtk

2/16/2026 at 7:27:40 AM

People are putting C++20 co-routines to good use in embedded systems, in scenarios where the language runtime with some additional glue layers, is the OS for all practical purposes.

And GPGPUs as well, like senders/receivers whose main sponsor is NVidia.

by pjmlp

2/14/2026 at 2:28:12 PM

But Zig's async is being designed to enable this low-level control.

by melodyogonna

2/15/2026 at 1:58:09 PM

There’s two things I think a low level language should have:

1. Standardise on a sync/async agnostic IO interface (or something similar) so you don’t get fragmentation in the ecosystem.

2. Stackless coroutines. Should give the most efficient async io code, and efficient code is one of the reasons I want to use low level language

by audunw

2/14/2026 at 6:30:11 PM

I am also positive, but when is the language going to hit a stable very LTS version that won't be touched for a long time?

If you want to compete with C, you can't do so without understanding that its stability and the developers focusing on mastering its practices, design, limitations, tooling has been one of the major successes.

by epolanski

2/14/2026 at 7:55:19 PM

> when is the language going to hit a stable very LTS version that won't be touched for a long time?

Is there any reason to be rushing it? Zig isn't languishing without activity. Big things are happening, and it's better in my opinion for them to get the big important stuff right early than it is to get something stable that is harder to change and improve later.

"Competing with C" means innovating, not striving to meet feature parity so it can be frozen in time. It's not as though C has anything terribly exciting going on with it. Let them cook.

by bastawhiz

2/14/2026 at 8:18:24 PM

There are so many other options available. If that is a concern, zig is not the answer now. Rushing to "LTS" would go completely against the ethos of constant experimentation and improvement that is and has been making zig great. C is 50 years old. Maybe give it a little time...

by allthetime

2/15/2026 at 8:51:55 AM

FWIW C++ has quite a few async I/O libraries that support io-uring. For example, ASIO has had a io-uring backend since 1.21 (late 2021).

by spacechild1

2/14/2026 at 7:16:26 PM

It's interesting to see this land while Rust support of io_uring in a mainstream library is lagging. And not for lack of trying, its just difficult to design a safe (zero-cost) idiomatic Rust abstraction over io_uring's completion based IO.

by Seattle3503

2/16/2026 at 7:24:52 AM

Doesn't look like this is done either,

> 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:

by pjmlp

2/16/2026 at 5:42:51 PM

Fair enough

by Seattle3503

2/14/2026 at 11:40:04 AM

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.

by lukaslalinsky

2/14/2026 at 12:57:35 PM

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.

by hu3

2/14/2026 at 2:04:23 PM

It doesn't say "minor" details like networking not being implemented :)

by lukaslalinsky

2/15/2026 at 1:46:43 AM

They probably probably thought that this warning was clear enough:

"should be considered experimental because there is important followup work to be done"

I guess not clear enough to some people.

by hu3

2/15/2026 at 1:46:20 PM

I think another way of thinking about this interface is: it’s kind of like an abstraction over Linux system calls and ntdll. It’s naturally gonna have a kind of subset of all the useful calls, with some wrapping.

I don’t see anything wrong with this, it’s kind of how Windows forces developers to use DLL to access syscalls (the syscall numbers can change) which IMO is a good architectural decision.

by audunw

2/16/2026 at 6:06:31 PM

Except it's not. I've implemented it, over its multiple iterations, so I'm familiar with it. It's an interface to satisfy the needs of the Zig compiler. It's heavily lacking for use in server applications.

by lukaslalinsky

2/14/2026 at 5:56:12 PM

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...

by srcreigh

2/14/2026 at 1:41:44 PM

I like that zig takes freestanding target seriously. And seems like 0.16 becomes even better for freestanding code reusability.

by Cloudef

2/14/2026 at 10:53:00 AM

Haven’t looked into MacOS internals for a while, happy to see they stuck to GCD, great middle ground for parallelisation

by khalic

2/14/2026 at 8:03:59 PM

I'm not a zig fan myself, but I'm glad to see a substantial project with momentum and vision moving ahead. It's not languishing. It's trying interesting new things. It's striving for incremental gains consistently over time.

There's a lot of hate in these comments. Nobody is forcing you to use Zig and it's not trying to be "done" right now. And in fact, if the only thing they were focusing on was putting a bow on the project to call it "1.0", it probably wouldn't achieve any of it's long term goals of being a mainstream systems programming language. If it takes another five years or fifteen, as long as the project moves forward with the same energy, it's going to be fine.

For a fairly small project that's largely one dude, this is far more than most of us have or could hope to ever achieve ourselves. Give the people putting in the work credit where credit is due.

by bastawhiz

2/14/2026 at 8:10:17 PM

Every once in a while I build a game engine with a tcp & udp multiplayer server to learn a new language. I started doing this with zig a couple months ago.

It might be because I've done it a few times now, and/or because of the existence of LLMs, but this is the most fun I've had doing, and the most productive I've been, and the engine absolutely rips performance wise.

Zig makes it very easy to do this kind of lowish-level data-oriented programming, and tbh, I'm hooked. I was using rust for my performance critical services but dancing around the strictness and verbosity of memory management in rust gives me nothing in comparison and just gets in my way. This is partially a skill issue, but life is short and I just want to make fast, well organized software that works.

by allthetime

2/14/2026 at 11:26:27 AM

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.

by BrouteMinou

2/14/2026 at 1:07:43 PM

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.

by flohofwoe

2/14/2026 at 1:21:16 PM

> 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).

by pron

2/14/2026 at 1:26:59 PM

> 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).

by flohofwoe

2/14/2026 at 1:38:56 PM

> 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.

by pron

2/14/2026 at 2:33:57 PM

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”.

by strawhatguy

2/14/2026 at 2:12:27 PM

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 :)

by andrepd

2/14/2026 at 2:19:30 PM

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++.

by zozbot234

2/14/2026 at 3:06:00 PM

> 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).

by kibwen

2/14/2026 at 6:17:03 PM

Only because Rust is a source only language for distribution.

One business domain that Rust currently doesn't have an answer for, is selling commercial SDKs with binary libraries, which is exactly the kind of customers that get pissed off when C and C++ compilers break ABIs.

Microsoft mentions this in the adoption issues they are having with Rust, see talks from Victor Ciura, and while they can work around this with DLLs and COM/WinRT, it isn't optimal, after all Rust's safety gets reduced to the OS ABI for DLLs and COM.

by pjmlp

2/14/2026 at 6:36:35 PM

I'm not expecting to convince you of this position, but I find it to be a feature, not a bug, that Rust is inherently hostile to companies whose business models rely on tossing closed-source proprietary blobs over the wall. I'm fairly certain that Andrew Kelley would say the same thing about Zig. Give me the source or GTFO.

by kibwen

2/14/2026 at 6:45:55 PM

In the end it is a matter of which industries the Rust community sees as relevant to gain adoption, and which ones the community is happy that Rust will never take off.

Do you know one industry that likes very much tossing closed-source proprietary blobs over the wall?

Game studios, and everyone that works in the games industry providing tooling for AAA studios.

by pjmlp

2/15/2026 at 1:38:07 AM

Tying yourself in a knot around ABI usually isn't worth it. You pick up to two: performance, ABI stability or adaptability.

And you can still internaly have it, if your deps have sources, or compile artifacts for only allow single Rust version (additional rules may apply).

There is work on Rust ABI (crabi), but there isn't a huge push for it.

by Ygg2

2/14/2026 at 7:11:22 PM

> Game studios, and everyone that works in the games industry providing tooling for AAA studios.

You know what else is common in the games industry? C# and NDA's.

C# means that game development is no longer a C/C++ monoculture, and if someone can make their engine or middleware usable with C# through an API shim, Native AOT, or some other integration, there are similar paths forward for using Rust, Zig, or whatever else.

NDA's means that making source available isn't as much of a concern. Quite a bit of the modern game development stack is actually source-available, especially when you're talking about game engines.

by LexiMax

2/14/2026 at 7:33:35 PM

Do you know what C# has and Rust doesn't? A binary distribution package for libraries with a defined ABI.

by pjmlp

2/15/2026 at 5:56:01 PM

100% agreed.

by AndyKelley

2/14/2026 at 10:21:46 PM

> I'm fairly certain that Andrew Kelley would say the same thing about Zig. Give me the source or GTFO.

Thus it will never be even considered outside the tech bubble.

by wolvesechoes

2/15/2026 at 12:13:49 AM

Rust allows binary libraries with a C ABI. Having safety within any given module is still a big deal, and it's hard to guarantee safety across dynamic modules when the code that's actually loaded can be overridden by a separately-built version.

by zozbot234

2/14/2026 at 6:13:40 PM

Compiler vendors are free to chose what ABI stability their C++ implementations provide.

ISO C++ standard is silent on how the ABI actually looks like, the ABI not being broken in most C and C++ compilers is a consequence of customers of those compilers not being happy about breakages.

by pjmlp

2/15/2026 at 1:59:02 AM

Yeah but ABI stability isn't really just magic dust you sprinkle in you language/compiler and make it more stable

It's a straightjacket that has application in few select cases.

Things ABI prevents in C++:

- better shared_ptr

- adding UTF8 to regex

- int128_t standardisation

- make most of <cstring> constexpr

And so on: https://cor3ntin.github.io/posts/abi/

I get you might have particular criteria on this. But it's a feature that comes with huge, massive downsides.

by Ygg2

2/14/2026 at 6:28:39 PM

> Compiler vendors are free to chose what ABI stability their C++ implementations provide.

In theory. In practice the standards committee, consisting of compiler vendors and some of their users, shape the standard, and thus the standard just so happens to conspire to avoid ABI breakages.

This is in part why Google bowed out of C++ standardization years ago.

by LexiMax

2/14/2026 at 6:43:39 PM

I know, but still go try to push for ABI breaks on Android.

by pjmlp

2/14/2026 at 6:27:51 PM

Sure, but considering that Zig is a modern C alternative, one should not and cannot afford to forget that C has been successful also because it stayed small and consistent for so long.

The entire C, C ABI and standard lib specs, combined, are probably less words than the Promise spec from ECMAScript 262.

A small language that stays consistent and predictable lets developers evolve it in best practices, patterns, design choices, tooling. C has achieved all that.

No evolving language has anywhere near that freedom.

I don't want an ever evolving Zig too for what is worth. And I like Zig.

I don't think any developer can resolve all of the design tensions a programming language has, you can't make it ergonomic on its own.

But a small, modern, stable C would still be welcome, besides Odin.

by epolanski

2/14/2026 at 7:14:43 PM

I'm pretty sure the point of aggressively evolving now is to have to basically not evolve it at some point in the future?

by dnautics

2/16/2026 at 7:32:00 AM

> The entire C, C ABI and standard lib specs, combined, are probably less words than the Promise spec from ECMAScript 262.

Not if you look into C23, include all the compiler extensions devs keep thinking are part of ISO C, and the "C ABI" is one per each existing OS written in C.

by pjmlp

2/14/2026 at 7:26:48 PM

Besides Odin? Does Odin give you most of this?

by bbkane

2/14/2026 at 2:09:42 PM

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.

by lukaslalinsky

2/14/2026 at 3:28:17 PM

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.

by lioeters

2/15/2026 at 7:54:57 AM

I've realized that Zig is a language, in which people can write programs in vastly different styles. And these are not really compatible. This is not unlike C++, for example. I learned Zig in my own bubble, just using my previous programming knowledge, not relaying on existing Zig code much. If I saw Zig's own code at the early stages, I'd probably not pick the language, purely on the style of huge inlined switches and nested conditions all over the place.

by lukaslalinsky

2/14/2026 at 3:35:39 PM

I dont think the core team accepts LLM generated code in the std.

by Cloudef

2/14/2026 at 3:26:36 PM

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.

by vlovich123

2/14/2026 at 3:29:35 PM

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.

by lukaslalinsky

2/14/2026 at 2:53:24 PM

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.

by solatic

2/14/2026 at 3:53:58 PM

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.

by ozgrakkurt

2/14/2026 at 4:30:50 PM

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

by ozgrakkurt

2/14/2026 at 4:01:36 PM

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

by ozgrakkurt

2/14/2026 at 4:49:55 PM

>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.

by DetroitThrow

2/14/2026 at 3:04:20 PM

> ...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.

by zozbot234

2/14/2026 at 3:11:49 PM

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.

by Tuna-Fish

2/14/2026 at 7:35:02 PM

Coming from Go, I'm really disappointed in Rust compiler times. I realize they're comparable to C++, and you can structure your crates to minimize compile times, but I don't care. I want instant compilation.

Zig is trying to get me instant compilation and I see that as a huge advantage for Zig (even past the first 2 weeks).

I'll probably stick with Rust as my "low level language" due to its safety, type system, maturity, library ecosystem, and career opportunities.

But I remain jealous of Zig's willingness to do extreme things to make compilation faster.

by bbkane

2/14/2026 at 8:06:29 PM

On any Go production projects I worked on or near, the incremental compile time was slower than C++ and Rust.

A full build was definitely much faster, but not as useful. Especially when using a build system with shared networked caching (Bazel for example).

Yes those projects were a bloated mess, as it always seems to be.

by bombela

2/15/2026 at 12:17:34 AM

Re: slower incremental compile times - not my experience, but interesting data point. I'll keep a look out for this.

by bbkane

2/14/2026 at 8:24:21 PM

The key with c++ is to keep coding while compiling. Otherwise..yeah you're blocked.

by samiv

2/16/2026 at 7:37:01 AM

The key with C++ is to learn how to use the build system, make use of binary libraries, and if one can afford to use the very latest compiler versions, modules.

And avoid header libraries, C++ isn't a scripting language.

by pjmlp

2/14/2026 at 3:20:33 PM

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).

by solatic

2/14/2026 at 3:34:42 PM

> 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.

by vlovich123

2/14/2026 at 4:05:25 PM

> 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.

by solatic

2/14/2026 at 4:13:34 PM

> 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.

by vlovich123

2/14/2026 at 5:44:34 PM

> 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.

by davemp

2/14/2026 at 6:03:04 PM

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.

by vlovich123

2/14/2026 at 7:19:56 PM

wow, what a list! all of these are statically analyzable using a slightly hacked zig compiler and a library!

https://github.com/ityonemo/clr

(Btw: you can't null pointer dereference in zig without using the navigation operator which will panic on null; you can't misalign a pointer unless you use @alignCast which will also create a panic)

by dnautics

2/16/2026 at 7:38:12 AM

I can also analyse C and C++ code for such issues, while keeping using a mature languages ecosystem.

by pjmlp

2/16/2026 at 1:26:00 PM

If you can statically analyze c for memory safety, why did pazlo bother building fil-C?

by dnautics

2/16/2026 at 4:30:23 PM

Where did I wrote that static analysis was enough on its own?

by pjmlp

2/16/2026 at 5:09:11 PM

Can you phrase that as a direct answer to my question? Trying to learn something here. Appreciate it!

by dnautics

2/16/2026 at 8:09:12 PM

I the sentence "I can also analyse C and C++ code for such issues, while keeping using a mature languages ecosystem." it is implied there are many tools that perform analysis of C and C++ code.

Some of those tools are static, others are dynamic, some require a special build, others are hybrid, others exist on all modern IDEs.

So it can be a mix of lint, clang tidy, VS analysis, Clion, ASan, USBsan, hardned runtimes, contracts (Frama-C), PVS, PurifyPlus, Insure++,....

by pjmlp

2/14/2026 at 10:56:08 PM

Neat. Why isn’t this in the main compiler / will it be? I’m happy to retract my statement if this becomes actually how zig compiles but it’s not a serious thing as it’s more a PoC of what’s possible today and may break later

by vlovich123

2/15/2026 at 12:49:16 AM

It will never be in the main compiler, since it was written by Claude. I think that's ok. The general concept is sound and won't break (modulo names of instructions changing etc). In fact it will get better. With the new io, concurrency checks will be possible

But also, there is no reason why it should have to be in the main compiler. I've architected it as a dlload plugin. It's even crazier! The output is a zig program which you must compile and run to get the final result.

by dnautics

2/14/2026 at 8:54:31 PM

This is pretty close to saying Rust is not very different than C because it has the unsafe keyword. That is, either an ignorant (of Zig) or disingenuous statement.

by davemp

2/14/2026 at 10:54:21 PM

To me the zig position is akin to saying that because Asan, TSAn and ubsan exist, c++ is safe because you’re just running optimized for performance.

If you believe I mischaracterized zig, please enlighten me what I got wrong specifically rather than attacking my ad hominem

by vlovich123

2/16/2026 at 7:39:46 AM

It is worse, because Asan, TSAn and ubsan already have several years of production experience, in a mature ecosystem.

There is no point throwing it all away to get back to the starting line.

by pjmlp

2/14/2026 at 11:40:50 PM

I’m not going to write a detailed response to something that’s extremely close to what an LLM responds to “what UB does zig have?”

Arguing about whether certain static analysis should be opt in or opt out is just extremely uninteresting. It’s not like folks are auditing the unsafe blocks in their dependencies anyways.

If you want to talk about actual type system issues that’s more interesting.

by davemp

2/15/2026 at 3:29:30 AM

So the Fermat defense? “I have the proof but the margin is too small”.

The proof is in the pudding. TigerBeetle despite having a quite opinionated style still almost hit by UB and basically got lucky it wasn’t a worse failure. By contrast, even though unsafe isn’t audited for all dependencies, it does in practice seem to make UB extremely unlikely. And there’s work ongoing in the ecosystem to create safe abstractions to remove existing unsafe into well tested and centralized things

by vlovich123

2/14/2026 at 4:15:06 PM

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

by ozgrakkurt

2/14/2026 at 6:04:45 PM

> 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

by vlovich123

2/15/2026 at 8:06:12 AM

I find it easier to write all the code I want in zig or c since it is easy to write low level code.

Hashmap is a good example to this. I was able to fairly easily port some parts of hashbrown to c but I’m pretty sure I can’t write that code in Rust in a reasonable amount of time.

by ozgrakkurt

2/14/2026 at 4:00:07 PM

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).

by program_whiz

2/14/2026 at 4:14:26 PM

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.

by vlovich123

2/14/2026 at 7:18:38 PM

It's possible to do memory safety analysis for zig. I think you could pretty easily add a noalias checker on top of this:

https://github.com/ityonemo/clr

by dnautics

2/14/2026 at 4:47:54 PM

> 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.

by wolvesechoes

2/14/2026 at 6:12:30 PM

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.

by LexiMax

2/15/2026 at 12:42:09 PM

People do under estimate how nice it is that the language ref or framework/tool documentation is all on one web page i can easily pdf print it and push it to my ipad for reading.

by dragonelite

2/14/2026 at 11:50:54 AM

For what it's worth, Bun is written in Zig (https://bun.sh/). The language isn't exactly in an early stage.

by warent

2/14/2026 at 12:05:44 PM

Oh but it is.

by eptcyka

2/14/2026 at 12:14:12 PM

Oh but it isn’t.

by tomalbrc

2/14/2026 at 2:38:03 PM

They just did a massive reactor that broke nearly 100% of existing code. Only an early language can do that.

by maleldil

2/14/2026 at 3:29:41 PM

What version are you referring to? I've had zero issues updating my zig stuff to 0.15.2 with frontier LLM assistance.

by pmarreck

2/14/2026 at 3:37:27 PM

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

by kccqzy

2/14/2026 at 5:31:47 PM

The huge change that will be passing Io objects around like you have with Allocator.

by maleldil

2/14/2026 at 6:11:48 PM

0.16 changes things around dramatically.

by the_mitsuhiko

2/15/2026 at 3:04:44 AM

Docs on this?

by pmarreck

2/15/2026 at 4:25:18 AM

Here[1]. This mentions async, but it affects every single use of IO functions.

[1] https://kristoff.it/blog/zig-new-async-io/

by maleldil

2/15/2026 at 8:51:20 AM

Also anything that reads environment variables.

by the_mitsuhiko

2/14/2026 at 2:16:43 PM

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.

by steeve

2/14/2026 at 2:29:37 PM

No shame in waiting for 1.0. Specially if you want to read docs rather than the code itself.

by rererereferred

2/14/2026 at 3:15:12 PM

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.

by BrouteMinou

2/14/2026 at 6:38:18 PM

People might be triggered by the word "worthless" but I totally get your point.

I hear great things about the language but only have so many hours in the day and so many usable neurons to spend in that day. Someday it would be nice to play with it.

The easiest way to embrace any new language is to have a compelling use to use it. I've not hit that point yet.

by pstuart

2/14/2026 at 11:43:28 AM

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.

by pygy_

2/14/2026 at 3:37:42 PM

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.

by dom96

2/14/2026 at 5:16:18 PM

Please stop posting 0-information-content complaints.

by srcreigh

2/14/2026 at 2:07:41 PM

> 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.

by wiseowise

2/14/2026 at 4:46:32 PM

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!

by DetroitThrow

2/14/2026 at 7:33:35 PM

I'm so sorry to hear about your diagnosis whatever it is :-P.

by crest

2/15/2026 at 8:49:10 AM

This is a very strange take. Isn't every pre 1.0 software like that. Heck there are some that claims to be 1.0 but then takes another 50 iteration of 1.51 before it reaches what should have been 1.0 in the first place.

I am not understanding the point here, do people expect they ship 1.0 before they know it is good or ready?

No wonder why software quality have deteriorated rapidly in the past 20 years.

by ksec

2/14/2026 at 1:55:22 PM

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.

by radarroark

2/14/2026 at 3:46:43 PM

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.

by dxdm

2/14/2026 at 2:04:17 PM

An AI will be able to handle updating your code for 95% of your breaking changes

by pmarreck

2/14/2026 at 2:13:45 PM

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.

by PaulRobinson

2/14/2026 at 3:14:17 PM

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.

by pmarreck

2/14/2026 at 4:09:31 PM

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!

by praveer13

2/16/2026 at 1:48:19 PM

yeah, I’ve noticed it do that too, it literally goes to the source and for all intents and purposes, “figures it out”

that’s why it sounds to me like these people commenting haven’t even used these models yet.

by pmarreck

2/14/2026 at 4:01:13 PM

> 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.

by flohofwoe

2/14/2026 at 2:27:40 PM

Just have to wait a few months until a new model with updated pretrained knowledge comes out.

by zozbot234

2/14/2026 at 2:51:13 PM

Or spend those few months doing the update :-)

by weakfish

2/14/2026 at 3:14:41 PM

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.

by Philpax

2/15/2026 at 10:13:59 AM

[dead]

by janlucien

2/14/2026 at 6:15:45 PM

As always with Zig posts, here come the haters. I really wonder why you even care about it. Can't we all be happy that Andrew and his team are doing their damnest to create something they believe in? Myself I am deeply inspired by their engineering spirit. In other posts I see people "worry" that Zig might not become mainstream. Why do people worry about these things? Just use the language if it helps you solve your problems. You don't need to treat it like an identity.

by portly

2/14/2026 at 8:52:04 PM

To make this go away, I think you’d have to change/mitigate the economic incentives (real and perceived) that influence programming practitioners.

People see the languages/libraries they use as their sellable articles. And why wouldn’t they? Every job application begins with a vetting of which “tools” you can operate. A language, as a tool, necessarily seeks to grow its applicability, as securing the ROI of if its users.

And even when not tied to direct monetary incentives, it can still be tied to one’s ability to participate and influence the direction of various open source efforts.

Mix in barely informed decision makers, seeking to treat those engineers as interchangeable assets, and the admirable position being promoted above falls down the priority chain.

by travisgriggs

2/14/2026 at 7:50:16 PM

This isn't a Zig-specific problem; the same thing has happened in waves for now decades on this site (see: Lisp, Ruby, Rust, etc).

> You don't need to treat it like an identity.

This is an eternal problem in this industry and it is by far the most annoying thing about it.

by Klonoar

2/14/2026 at 8:16:47 PM

Is it really a problem with the industry or is this the sort of thing where discussions go on forever on message boards where no one is in charge and people aren’t trying to work together to some actual goal, but where industry doesn’t suffer from the same problems?

by dan-robertson

2/14/2026 at 8:13:02 PM

The cool thing is, when you get even a whiff of this kind of tribal fan-boy bs from someone, you can just ignore it, move on, and continue learning, building, and discussing with positive productive people who share the same motivations. Life is too short to be bickering with haters in comment sections.

by allthetime

2/14/2026 at 10:42:42 PM

> As always with Zig posts, here come the haters. I really wonder why you even care about it.

It's another language stack that would need to be maintained within Linux distributions for years to come (security support, architecture support etc).

Upstream developers always seem to assume that there is no cost associated to introducing new software stacks. But in the end, someone has to maintain it. And they keep forgetting the purpose of software is to serve users, not developers.

And I'm not sure what's so revolutionary about Zig that couldn't have been solved by improving other languages.

For Zig in particular, the language isn't even stable enough that you can compile packages like Ghostty with any recent version of the Zig compiler. It has to be a very specific version of the compiler.

by cbmuser

2/14/2026 at 10:56:08 PM

No. If you don't want to maintain it, don't package it, or for that matter programs written in it. Yes, there are valid reasons not to use zig from a stability perspective, but just ignore it if it isn't good enough for your standards.

Personally I'm glad that there are more people trying to break out of the C tar pit. Even if I'd never chose to use the language.

by yxhuvud

2/15/2026 at 12:19:27 AM

> And they keep forgetting the purpose of software is to serve users, not developers.

Developers are the users of these software stacks though? I don't really understand your point.

by reppap

2/15/2026 at 1:08:37 AM

> And they keep forgetting the purpose of software is to serve users, not developers.

I don't have any horse in the game, but I do think Zig is interesting. This remark is funny to me because it's literally one of the tenets the Zig devs make decisions by!

https://ziglang.org/documentation/master/#Zen

> * Together we serve the users.

by ekipan

2/14/2026 at 7:04:21 PM

A mainstream language has predictable library-ecosystem support for most use-cases.

by derefr

2/14/2026 at 8:17:54 PM

A language, and by definition it's libraries, does not have to solve most use cases.

by beAbU

2/14/2026 at 10:44:30 PM

A new software stack isn't free. Someone has to maintain it.

And if the new software stack just improves a fraction of the ecosystem, it isn't worth the effort.

by cbmuser

2/14/2026 at 7:15:20 PM

It's not v1.0 and they don't claim to be.

So what is your point?

by hu3

2/15/2026 at 5:15:15 AM

I was directly answering the GP poster's posed question. Let me rearrange that question for readability:

> Why do people "worry" about Zig potentially never becoming mainstream?

There are people who want to learn Zig because they're excited to gradually transition their way away from some other ecosystem, and into the Zig ecosystem, as the Zig ecosystem takes root and develops.

But they don't want to regret that decision. They don't want to end up in a place where they're writing blog posts about how much they love Zig, and are the maintainer of five popular Zig libraries, and yet still feel forced to use C++ for their next actual app project (where they're then mostly unable to make use of those Zig libraries!) just because Zig, not being sufficiently "mainstream", can't attract/force the corporate owners of big fat libraries (Vulkan, CUDA, LLVM, etc) to invest effort into integrating with it, and continuously maintaining those integrations for it (i.e. including a Zig build in their CI matrix, so that their upstream changes can't silently break that integration.)

by derefr

2/14/2026 at 9:18:11 AM

[flagged]

by gethly

2/14/2026 at 9:29:54 AM

Instead of debating for years (like other languages), zig just tries things out. Worst case you can always rollback changes.

IMO best APIs and designs are those that are battle tested by end users, not won in an argument war during committee meetings.

This makes zig unique. It's fun to use and it stays fresh.

You can always just stay on older version of zig. But if you choose to update to newer version, you get new tools to make your code tidier/faster.

by BonusPlay

2/14/2026 at 9:57:15 AM

Other languages debate for years, because they have a customer base with important applications into production that don't find funny that their code is broken with experiments.

Zig is years away to become industry relevant, if at all, of course they can experiment all they like.

by pjmlp

2/14/2026 at 10:03:37 AM

Obviously, that comes with the language being in beta. If you don't want things broken, use a complete language.

by Pay08

2/14/2026 at 10:16:59 AM

It's hard to imagine Zig ever becoming stable and conservative. Even at 10 years old, it's still as beta as ever. At some point the churn becomes part of the culture.

Not a complaint, just an observation. I like that they are trying new things.

by zarzavat

2/14/2026 at 10:35:46 AM

I wouldn't be so sure about that. I do think there's a bit of scope creep, especially with the LLVM replacement stuff, but I don't think it's bad enough for the language to never come out. Most notable languages have at least one large corporate sponsor behind them, Zig doesn't.

by Pay08

2/14/2026 at 10:45:48 AM

I’m a casual user and the 0.16 changes scare me. I tried multiple attempts now, even with full LLM support to upgrade and the result is just a) painful and b) not very good. I have high doubts that the current IO system of 0.16 will make it for another release given the consequences of their choices.

by the_mitsuhiko

2/14/2026 at 11:32:09 AM

Here's some advice:

1. if you're a casual user (ie you don't follow the development) don't try incomplete APIs that not even the creators of fully know how they are supposed to work (because they're still tinkering with them) also you can't expect docs until the design is somewhat finalized (which is not yet, fyi)

2. llms don't help when trying to make sense of the above (a feature that is not complete, that has no docs other than some hints in commit messages, that changes every other commit), reserve llms for when things are stable and well documented, otherwise they will just confuse you further.

If you want to try new features before they land in a tagged release, you must engage with the development process at the very least.

by kristoff_it

2/14/2026 at 12:04:45 PM

> if you're a casual user (ie you don't follow the development) don't try incomplete APIs that not even the creators of fully know how they are supposed to work

Is the completeness of each API formally documented anywhere? Maybe I missed something but it doesn't seem like it is, in which case the only way to know would be to follow what's happening behind the scenes.

by jsheard

2/14/2026 at 8:06:47 PM

Zig cuts releases. This API is not on a release of Zig yet. It's only available through nightly builds of master. "Casual users" should stick to releases if they don't want to deal with incomplete APIs.

by Zambyte

2/14/2026 at 10:13:40 PM

That's not really the issue. The stable API is incompatible with the API that will launch with 0.16. It's not really relevant if I'm playing with incompletely API, I want to know how I can migrate to it. I did not move yet to 0.16, but I wanted to see.

The migration pain will be the same once it launches unless they revert back, which does not seem likely at all.

But the point is: potentially every API is unstable.

by the_mitsuhiko

2/14/2026 at 12:13:58 PM

> if you're a casual user (ie you don't follow the development) don't try incomplete APIs that not even the creators of fully know how they are supposed to work

From what I can tell pretty much everything can be broken at any point in time. So really the only actual advise here is not to use the language at all which is not reasonable.

> llms don't help when trying to make sense of the above

That has not been my experience. LLMs were what enabled me to upgrade to 0.16 experimentally at all.

> If you want to try new features before they land in a tagged release, you must engage with the development process at the very least.

No, that is unnecessary gatekeeping. 0.16 will become stable at one point and I don't want to wait until then to figure out what will happen. That's not how I used Rust when it was early (I always also tried nightlies) and that line of thinking just generally does not make any sense to me.

The reality is that Zig has very little desire to stabilize at the moment.

by the_mitsuhiko

2/14/2026 at 12:40:11 PM

The flipside of that is that the incomplete API should be in a separate branch until it is ready to be included in a release, so that people can opt in instead of having to keep in mind what parts of the API they aren't supposed to be using. It doesn't seem like you expect the changes to be finalised in time for 0.16.

by Pay08

2/14/2026 at 10:33:26 AM

I think it benefits the overall ecosystem for them to experiment so other languages can take what works

by nickorlow

2/14/2026 at 10:35:10 AM

> Instead of debating for years (like other languages), zig just tries things out.

Many other languages do try things out, they just do it in a separate official channel from the stable release or unofficial extensions. Depending on how many users the language has, that may still be more implementation experience than Zig making all devs try it.

I suspect the actual difference is the final decision making process rather than the trial process. In C++, language extensions are tried out first (implementation experience is a requirement for standard acceptance) but committee debates drag on for years. Whereas Python also requires trial periods outside the stable language but decisions are made much more quickly (even now that there's a steering rather than single BDFL).

by quietbritishjim

2/14/2026 at 10:05:55 AM

This is a great point, and it's actually something I really enjoy that the JVM and Java do nowadays by namespacing the new experimental APIs that you test from release to release and then it's stabilized like that, and becomes broadly available.

by jiehong

2/14/2026 at 11:18:50 AM

> IMO best APIs and designs are those that are battle tested by end users

Battle testing an API however requires time and the API to not constantly change.

by SkiFire13

2/14/2026 at 9:39:29 AM

> Instead of debating for years (like other languages), zig just tries things out.

So did Rust pre-1.0

Stability guarantees are a pain in the neck. You can't just break other people's code willy nilly.

> This makes zig unique. It's fun to use and it stays fresh.

You mean like how Rust tried green threads pre-1.0? Rust gave up this one up because it made runtime too unwieldy for embedded devices.

by Ygg2

2/14/2026 at 11:07:31 AM

Just on this point:

> You mean like how Rust tried green threads pre-1.0? Rust gave up this one up because it made runtime too unwieldy for embedded devices.

The idea with making std.Io an interface is that we're not forcing you into using green threads - or OS threads for that matter. You can (and should) bring your own std.Io implementation for embedded targets if you need standard I/O.

by alexrp

2/14/2026 at 1:16:59 PM

Ok. But if your program assumes green threads and spawn like two million of them on target that doesn't support them, then what?

The nice thing about async is that it tells you threads are cheap to spawn. By making everything colourless you implicitly assume everything is green thread.

by Ygg2

2/14/2026 at 9:38:08 AM

This is my favourite way to iterate, but the hard lesson is at some point after trying a bunch of things comes the Big Cleanup (tm). Is that a potential issue for this with Zig?

by interstice

2/14/2026 at 9:55:42 AM

From my perspective zig doesn't have "big cleanup" upfront. It's removing older features as it goes.

stdlib changes as it wants from version to version. So do language features. Since zig is pre-1.0, zig foundation isn't scared of breaking changes.

by BonusPlay

2/14/2026 at 9:46:18 AM

0.16's IO API changes might be that cleanup.

by SSLy

2/14/2026 at 10:58:52 AM

> Instead of debating for years (like other languages), zig just tries things out.

Good

> Worst case you can always rollback changes.

No, you cannot. People will leave in masses. In perl they announced experiments with a mandatory use experimental :feature. You couldnt publish modules with those, or else you are at risk.

This made perl exciting and fresh. Python on the other hand constantly broke API's, and had to invent package version locks and "safe" venv's. Which became unsafe of course.

Languages and stdlib are not playgrounds. We see what came out of it with C and C++ with horrible mistakes getting standardized.

by rurban

2/14/2026 at 11:17:08 AM

I recently ditched zig because of this.

I thought it was stable enough initially but they completely broke fuzz testing feature and didn’t fix it.

Also build system API and some other APIs change and it is super annoying.

Find it much better to use c23 with _BitInt integers and some macros and context passing for error handling.

Also some things like stack traces were broken in small ways in zig. It would report wrong lines in stack traces when compiling with optimizations. Also wasn’t able to cleanly collect stack traces into strings in production build.

It is understandable that breaking APIs is good for development but in most cases new API isn’t that good anyway.

And recently saw they even moved the time/Instant API to some other place too. This kind of thing is just super annoying with seemingly no benefit. Could have left the same API there and re-used it from somewhere else. But no, have to make it “perfect”

by ozgrakkurt

2/14/2026 at 11:39:56 AM

It sounds like you expected 1.0 stability from a language that isn't 1.0.

> I thought it was stable enough initially but they completely broke fuzz testing feature and didn’t fix it.

From the 0.14.0 release notes:

> Zig 0.14.0 ships with an integrated fuzzer. It is alpha quality status, which means that using it requires participating in the development process.

How could we possibly have been more explicit?

Fuzzing will be a major component of Zig's testing strategy in the long term, but we clearly haven't had the time to get it into shape yet. But we also didn't claim to have done!

> Also some things like stack traces were broken in small ways in zig. It would report wrong lines in stack traces when compiling with optimizations. Also wasn’t able to cleanly collect stack traces into strings in production build.

I mean, to be fair, most compiled languages can't give you 100% accurate source-level stack traces in release builds. But that aside, we have actually invested quite a lot of effort into std.debug in the 0.16.0 release cycle, and you should now get significantly better and more reliable stack traces on all supported platforms. If you encounter a case where you don't, file a bug.

> And recently saw they even moved the time/Instant API to some other place too. This kind of thing is just super annoying with seemingly no benefit. Could have left the same API there and re-used it from somewhere else. But no, have to make it “perfect”

I acknowledge that API churn can be annoying, but it would be weird not to aim for perfection prior to 1.0.

by alexrp

2/14/2026 at 1:49:15 PM

Makes sense, that is fair.

I was a bit too frustrated with all these changes and zig wasn’t the right choice for my particular use case then.

by ozgrakkurt

2/14/2026 at 12:32:25 PM

Rust has stable vs nightly. Nightly tries things and makes no guarantees about future compatibilities. If you need code that builds forever, you stay on stable. There's no reason Zig couldn't have the same.

by speed_spread

2/14/2026 at 9:43:08 AM

I have my doubts on Jai, besides being built towards game development, from what I read/watched about it, it has 2 or 3 meta programming capabilities, like comptime, macros, etc it feels too much of the same, also Jai is not built towards correctness or safety, John mentality is that he knows what he is doing, so he doesn’t need those guardrails and he wants instead expressiveness.

Also Jai is like C++ in complexity, while Zig is similar to C, very simple language.

Carbon is vaporware so far, there’s no language that could be used yet, because they first need to solve the C++ interop and fast compilation times, that is what will shape the language, so no one is using it, because it doesn’t exist yet.

by norman784

2/14/2026 at 9:56:57 AM

Remember that it was Jai that inspired all these new languages. When you talk about the capabilities like comptime, that's all from Jai and why John no longer does public presentations(as people keep stealing his unfinished ideas).

Your comment about gamedev focus makes no sense as that it the most hardcore segment of all the programming there is. So if a language is good for gamedev, it's good for everything else - with high performance.

I'm still in the GC camp with Go and don't see myself leaving any time soon but Zig is just rust-fugly and takes for ever to complete(it started 10 years ago, mind you). Odin is essentially complete, just lacks official spec. I like it but can' bring myself to use it as it lacks methods and I won' be going back to writing a procedural code like its 2002.

I'm curious to see Jai being released, despite having no use case for it. My initial post is merely about purposefulness, or the lack of, for named programming languages as nowadays John's name will carry more weight than Zig could ever have. so without Zig being 1.0 after a decade, and having no competitive advantage over Jai, it has no chance to survive after Jai is released. As I said, Odin will likely will as it is quite simpler, more niche language. Zig just goes directly against Jai and it will lose.

by gethly

2/14/2026 at 11:47:27 AM

> When you talk about the capabilities like comptime, that's all from Jai

You really should learn a few new languages if you think that’s remotely true. For example, Lisp macros are the distant ancestors of most metaprogramming techniques, dating from the 60s. But there are many similar techniques that precede Zig comptime and Jai, like D’s mixins and templates, which together have very similar power to comptime. There are also Nim macros which I believe also precede Jai. Even the C preprocessor could probably be considered an inspiration for anyone creating a C competitor before we need to invoke Jai ideas.

by brabel

2/14/2026 at 1:48:23 PM

> Remember that it was Jai that inspired all these new languages

You’ve made this claim on here before and when I asked you to substantiate it with a source you were completely unable to.

by _bohm

2/14/2026 at 10:03:45 AM

> why John no longer does public presentations(as people keep stealing his unfinished ideas)

That's your opinion or you have a source for that?

by Phil_Latio

2/14/2026 at 10:26:29 AM

he said it in a video, i think it was in the recent wookash podcast. although you might fing a short clip of the segment somewhere.

by gethly

2/14/2026 at 11:00:26 AM

The idea of languages "stealing" ideas from each other is not something anyone building a language cares about. I'll just charitably assume you've completly misinterpreted something he said.

by Fraterkes

2/14/2026 at 10:42:05 AM

> Remember that it was Jai that inspired all these new languages.

Not really. Rust was a thing long before Jai.

by Matl

2/14/2026 at 11:54:20 AM

Not sure why this is being downvoted, Blow started working on Jai in 2014, by which point Rust was already nearing stabilization with 1.0 shipping in 2015.

by jsheard

2/14/2026 at 12:37:21 PM

In fact Rust was specifically discussed as a possible alternative to the C++ status quo in Jon's initial "A Programming Language For Games" talk which roughly marks the inception of his current / upcoming language.

by king_geedorah

2/14/2026 at 10:55:42 AM

> as nowadays John's name will carry more weight than Zig could ever have.

I'm sorry but Zig has been used to create actual production software for many companies whereas Jai has been used maybe once for a mediocre game.

by LunaSea

2/14/2026 at 12:55:41 PM

You sound like you're in a cult

by cassepipe

2/14/2026 at 9:48:54 AM

>Also Jai is like C++ in complexity, while Zig is similar to C, very simple language.

And most importantly, Zig is aiming at being a C++ replacement with the simplicity of C, it is not trying to replace C.

by ofalkaed

2/14/2026 at 10:01:09 AM

I think you meant to say Jai, not Zig.

by Pay08

2/14/2026 at 9:54:18 AM

Good luck with that, it is basically Modula-2 with C like syntax, and we aren't even getting into the whole ecosystem that it is missing on.

Any C++ or C replacement will need to win the earths of mainstream OS and game console vendors, otherwise it will remain yet another wannabe candidate.

Those have already their own languages, alongside their own C and C++ compilers, and are only now starting to warm up to Rust.

Zig or any other candidate will have a very hard time being considered.

by pjmlp

2/14/2026 at 10:12:00 AM

So no one should even try because they will never win over all of the C/C++ crowd so are doomed to fail and forever to be a wannabe? I think Andrew has gone about things in a good way, going back to C and exploiting hindsight, not trying to offer everything as quickly as possible. Extend C but keep C interoperability and do both better than C++ instead of trying to be the next big thing and he goes about it in a very deliberate and calculated way. He may not succeed, but the effort has given us a great deal.

by ofalkaed

2/14/2026 at 10:42:10 AM

One should try, while being aware of the realities of language adoption.

I disagree Zig is that great deal of a language, it would have been if we were talking about 1990's programming language ecosystem, not in 21st century.

Use-after-free problems should not be something we still need to worry about, when tooling like PurifyPlus trace back to 1992.

by pjmlp

2/14/2026 at 11:12:42 AM

I don't think Andrew believes Zig is going kill C or C++, he probably has hope but I think he is aware of the reality. He found a way to make a living on something he was passionate about.

Use-after-free is a fact of life until something kills C, but the realities of language adoption are against that. Zig seems interesting and worthwhile in offering a different perspective on the problem and does it in a way more agreeable than Rust or the like for all those who love C and are adverse to large complex languages. The realities of language adoption are as much for as against Zig, large numbers of people are still getting drawn to C and Zig seems to do a better job addressing why so many are drawn to it than the alternatives.

by ofalkaed

2/14/2026 at 11:37:01 AM

For that to matter OS vendors that only care about C on their platforms, have to also care about Zig.

Otherwise the only users are going to be the ones happy to do some yak shaving instead of the actual application code with the vendor tools.

It also ignores that C doesn't stand still, the competition is C2y, not C89.

by pjmlp

2/14/2026 at 9:51:49 AM

Kinda weird to blame Zig for not being at 1.0 yet while Jai is still in closed beta after 11 years. Meanwhile Zig is being in used in big-ish projects all over while Jai has... a single game engine? Jai looks cool but it's far far FAR behind and losing ground.

by WJW

2/14/2026 at 10:47:54 AM

The fallacy of that argument would be if its author would seek adoption, however like Naughty Dog with their Lisp based language, John has no plans to have Jai win world adoption beyone his game engine.

by pjmlp

2/14/2026 at 11:24:47 AM

That may be, but OP tried to claim that

> once Jai comes out, Zig will become obsolete

If Jai is happy to have limited adoption (which is fine), other languages will by definition not be displaced by Jai. That is even if we accept OPs implied point, that Jai is good enough to displace Zig, without further discussion. But even that seems to be rather doubtful.

by WJW

2/14/2026 at 11:33:35 AM

Agreed, however I also think Zig will be another Coffee Script, PureScript, Elm,...

I advise to revisit HN posts about them.

by pjmlp

2/14/2026 at 12:21:52 PM

Sure, but Zig has way more money and people working on it. And Jai has inspired all of these new languages so all they had to do was to steal John's ideas whereas he had to actually think very hard about them and do countless iterations to come to a solid conclusion. He paid the cost, they reaped the benefits. So Zig being 10 years old and unfinished just shows they have no original thought, or a plan for that matter.

by gethly

2/14/2026 at 10:09:38 AM

> Jokes aside

Ok ok, good

> once Jai comes out

Dangit! You couldn't even make it to the end of the sentence.

by dmit

2/14/2026 at 11:32:28 AM

When in comes to programmming languages, I would rather see a language done right after 20 years of development than what we see today with all mainstream languages splatting features and breaking changes without care for overall language conciesness and usability.

See Python 2->3, Rust async traits, Go generics, C++... basically everything.

by ivanjermakov

2/14/2026 at 9:40:14 AM

There are high profile apps written in Zig, Bun (bought by Anthropic) and Ghostty also Uber use it. What apps are written in Jai or Odin.

by small_model

2/14/2026 at 9:20:41 AM

I feel like this is doomerism with high bias - i'm sorry but there is nothing founded here ; for all I know ; if Zig is able to put only one good reason to be used - some people will use it and not care - however this is a purely logical statement and I do not know of Zig so I might be blind here.

by 6r17

2/14/2026 at 9:53:47 AM

Being at 0.16 right now does not mean much. From what I gather, he is more focused on the semantics right now and trying to avoid getting bitten by a lack of foresight down the road, as most every language is. Things will probably start moving more quickly as the language solidifies.

by ofalkaed

2/14/2026 at 10:20:29 AM

Any backwards compatible language will accumulate hindsight errors. It's practically inevitable.

by Ygg2

2/14/2026 at 9:20:00 AM

Can you elaborate? Zig has a lot of traction already.

by cloudhead

2/14/2026 at 9:58:38 AM

Except for Tiger Beetle customers and the few ones using Bun, what traction?

by pjmlp

2/14/2026 at 11:24:07 AM

Ghostty

https://ghostty.org

by tosh

2/14/2026 at 11:34:35 AM

Another one to the list, however it hardly sounds like a killer application.

by pjmlp

2/14/2026 at 11:49:15 AM

It's been my daily driver for close to a year now. It might not be a killer application, but it's certainly enough to prove Zig isn't vapourware.

by pdpi

2/14/2026 at 1:37:24 PM

If that is enough, there are plenty of languages around that fit the bill.

by pjmlp

2/14/2026 at 10:30:14 AM

I've read Bun is just a wrapper, not actual Zig implementation anyway. Also, making a financial database in beta language that constantly changes and breaks is "really smart".

by gethly

2/14/2026 at 10:36:05 AM

A wrapper over what?? Bun includes the JavaScriptCore engine for JS evaluation, but it's so much more.

As for financial database concerns, if you're serious about including a project like that in your system, you have thorough correctness and performance testing stages before you commit to it. And once it passes the hurdles, at that point what difference does it make if it's written in a beta language, or a bunch of shell scripts in a trench coat, or whatever.

by dmit

2/14/2026 at 11:29:55 AM

Ghostty.

by pdpi

2/14/2026 at 10:40:44 AM

ZML

by steeve

2/14/2026 at 10:44:15 AM

What is even that? Not bothering to Google for it, which shows how irrelevant it is.

by pjmlp

2/14/2026 at 10:47:08 AM

Good call, for bad reasons.

> At ZML, we are creating exciting AI produ[...]

by dmit

2/14/2026 at 10:04:39 AM

Let it come out before we get to chest beating. We are talking about shipped features in Zig here.

by gigatexal

2/14/2026 at 9:47:03 AM

WalterBright reply in 3...2...1...

by xeonmc

2/14/2026 at 11:03:12 AM

You're right that zig is vaporware - not because of other languages - but because programming is going away entirely.

by jpnc

2/14/2026 at 11:56:32 AM

I’m waiting for the kqueue implementation.

by nesarkvechnep

2/14/2026 at 5:09:44 PM

When a language starts to do this kind of thing, you know it isn’t going to replace C.

by up2isomorphism

2/14/2026 at 12:07:45 PM

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.

by small_model

2/14/2026 at 1:15:41 PM

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).

by flohofwoe

2/14/2026 at 5:26:27 PM

> 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.

by junon

2/14/2026 at 6:35:24 PM

C? Never. I feel like that ship has sailed, it's too primordial and tied to too many system ABI's to ever truly go away. I think we'll see a lot of Rust or Zig replacing certain popular C programs and libraries, but I don't think C will ever go away.

C++ on the other hand? Possibly, though I think that it's just as much because of the own-goals of the C++ standards committee as it is the successes of Rust. I don't really consider Zig a competitor in this space because if you're reaching for C++, you are reaching for a level of abstraction that Zig is unwilling to provide.

by LexiMax

2/15/2026 at 12:18:21 AM

They said the same thing about Fortran, COBOL, etc. Still "around" but not the de facto.

by junon

2/14/2026 at 10:22:10 PM

Is it? rust has to ditch llvm to be able to replace c++ - or rewrite llvm in rust.

by cv5005

2/14/2026 at 2:03:10 PM

> 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.

by sgt

2/14/2026 at 3:25:57 PM

> 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.

by grayhatter

2/14/2026 at 2:33:32 PM

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.

by zozbot234

2/14/2026 at 4:03:54 PM

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

by ceteia

2/14/2026 at 3:13:17 PM

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.

by kartoffelsaft

2/14/2026 at 4:05:16 PM

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/

by ceteia

2/14/2026 at 6:30:31 PM

There is an announcement already planned at NDC Toronto 2026.

> Carbon: graduating from the experiment

https://ndctoronto.com/agenda/carbon-graduating-from-the-exp...

As for it being widely adopted, people keeping missing the point that Carbon is mostly for Google themselves, as means to integrate into existing C++ projects.

They are the very first ones to assert that for green field projects there are already plenty of safe languages to chose from.

by pjmlp

2/14/2026 at 7:01:40 PM

What concerns me is that the design of Carbon in aspects seem to have serious issues already now.

In case that you are well familiar with for instance pattern matching, might you have any opinions on the pattern matching that is currently proposed for Carbon?

https://docs.carbon-lang.dev/docs/design/pattern_matching.ht...

by ceteia

2/14/2026 at 7:24:30 PM

I am not a Google employee, as such I don't care where they take Carbon, other than being a technology nerd that had compiler design as one of the areas I majored in.

Regarding the linked pattern matching proposal, it seems alright to me, not everything has to be ML like.

by pjmlp

2/14/2026 at 8:04:20 PM

Are you really OK with runtime "expression patterns"?

    match (0, 1, 2) {
      case (F(), 0, G()) => ...
    }
> Here (F(), 0, G()) is not an expression, but three separate expressions in a tuple pattern. As a result, this code will call F() but not G(), because the mismatch between the middle tuple elements will cause pattern matching to fail before reaching G(). Other than this short-circuiting behavior, a tuple pattern of expression patterns behaves the same as if it were a single expression pattern.

How would that work with exhaustiveness checking? As far as I can tell, they themselves believe that Carbon's exhaustiveness checking will be very poor.

And OK with implicit conversions? Especially when combined with their way of handling templates for pattern matching?

by ceteia

2/14/2026 at 9:25:05 PM

As mentioned I have no interest in ever using Carbon, the language still isn't 1.0, and full end to end compiler is yet to be made available.

by pjmlp

2/14/2026 at 5:19:07 PM

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.

by sgt

2/14/2026 at 6:54:46 PM

That's the space where Go shines

by giovannibonetti

2/14/2026 at 2:09:15 PM

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...)

by pmarreck

2/14/2026 at 6:26:32 PM

That doesn't mean Microsoft, Google, Apple, Sony, Nintendo, AMD, Intel, NVidia will be jumping into Zig any time now, just because some HN celebrities blogged about it.

Those are the companies I care about when chosing which programing languages to invest my time on.

by pjmlp

2/14/2026 at 5:02:42 PM

> 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

by wolvesechoes

2/14/2026 at 10:49:33 PM

I'm not sure why your comment is being downvoted, but it's spot on.

Rust has definitely gained some ground while they're hardly any relevant products using Zig.

by cbmuser

2/14/2026 at 12:54:07 PM

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.

by testdelacc1

2/14/2026 at 8:23:08 PM

Their own libc project is wicked. They are gradually replacing C implementations with zig and in the mean time the C implementations effortlessly link and compile in the same compilation unit as the zig code.

by allthetime

2/14/2026 at 1:05:50 PM

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.

by zozbot234

2/14/2026 at 3:26:03 PM

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.

by kartoffelsaft

2/14/2026 at 4:43:59 PM

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.

by phicoh

2/14/2026 at 4:57:42 PM

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.

by zozbot234

2/14/2026 at 5:15:56 PM

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.

by phicoh

2/14/2026 at 5:35:33 PM

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.

by zozbot234

2/14/2026 at 3:35:17 PM

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.

by zozbot234

2/14/2026 at 4:06:57 PM

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.

by Quothling

2/14/2026 at 6:24:14 PM

I guess C++ teams at Microsoft, Google, IBM, Adobe don't count.

by pjmlp

2/14/2026 at 7:22:53 PM

It's not as widespread in these companies as you and many Rust evangelists imply it is.

Specially because it's not a drop-in replacement for C++. As Zig is for C.

So when Zig hits 1.0 these companies will probably consider Zig much more than they do today. Understandably.

by hu3

2/14/2026 at 7:30:35 PM

First of all, if I am an evangelist of anything, it is about safe systems programming with automatic resource management languages, if I had a magic wand, we would be talking about languages like D and AOT C#, not Rust.

Secondly, let us know when Amazon rewrites Firecracker in Zig, Android replaces Rust with Zig, or Mark Russinovich goes to some Zig conference explaining why Azure is dropping Rust for Zig,

"Mark Russinovich, Microsoft Azure CTO tells Rust Nation UK 2025 why Azure is moving to Rust from C++"

https://www.youtube.com/watch?v=SmUprpjCWjM

by pjmlp

2/15/2026 at 1:36:39 AM

Great clickbait title for a Rust conference.

But in the video he says they are starting with critical systems first.

Emphasis on starting.

So yeah, not as pervasive as you, the evangelists or that video title implies.

by hu3

2/15/2026 at 10:13:38 AM

You could have checked his conference talk as well, instead of downplaying the interview.

"Microsoft is Getting Rusty: A Review of Successes and Challenges - Mark Russinovich"

https://www.youtube.com/watch?v=1VgptLwP588&t=1903s

The only Microsoft divisions that are still all are into C++ is Windows and XBox, and still, C++/WinRT is now in maintenace, the team has moved into windows-rs, WDK now has Rust bindings available.

by pjmlp

2/15/2026 at 12:03:55 AM

Not if you want a job near the town in Denmark where I live.

by Quothling

2/15/2026 at 10:14:32 AM

Does any of them offer C++ positions near that town?

by pjmlp

2/15/2026 at 4:09:17 PM

Microsoft and IBM don't. Then they don't really post jobs for their own stuff. It's mainly to sell consultant services like selling Mainframe SWE's service to banks. If you mean jobs in my area in general then there are a lot of places that offer C++ jobs.

by Quothling

2/14/2026 at 1:04:12 PM

> 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. :)

by pron

2/14/2026 at 2:16:27 PM

> 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…

by metaltyphoon

2/14/2026 at 3:18:55 PM

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).

by pron

2/14/2026 at 6:38:51 PM

To this day C++ has hardly won the hearts of C devs on the embedded space, on both sides of the camp there are individuals that start religious discussions about the C/C++ abreviation, there is something like Orthodox C++ that basically means using C++ compiler to write what is mostly Better C, and most frameworks that were so hyped in the 1990's are now gone, or subsyst in maintenance contracts on applications that when the time gets to be rewritten it won't surely be C++.

So even though C++ is the language I reach for outside Java, C#, TypeScript, I would assert that downplaying Rust adoption by Amazon, Adobe, Microsoft, Google, is losing track where things are going.

by pjmlp

2/14/2026 at 8:08:52 PM

Downplaying compared to what? This kind of adoption is certainly something Haskell never gained. But all those companies (or analogous ones) adopted C++ much faster. In fact, they've adopted faster virtually every language they're using seriously. So it's a great achievement compared to every language they've never adopted at all, but not such a great achievement compared to every other language they have adopted.

> that when the time gets to be rewritten it won't surely be C++.

It looks like it won't be Rust, either. I mean, some may be written in Rust, but not the majority. My point is just that as much as some erstwhile Haskell fans have taken to Rust, comparing Rust's adoption to Haskell's - a language whose joke motto was "avoid success at all costs" - is not the right metric. Given that Rust's goal was to replace C++, its success should be compared to C++ and other languages that ended up achieving similar success. I'm saying that compared to them Rust's success has been mediocre, if that, and it's not a young language anymore by any stretch of the imagination.

by pron

2/14/2026 at 9:18:46 PM

I don't have a use for Rust on my daily work, and would rather see Java finally adopt the features it missed down from Oberon and Modula-3 for systems programming, however we will have to disagree on the "mediocre" adoption.

So many language designers would dream to have such adoption numbers by tech giants for their hobby language.

by pjmlp

2/15/2026 at 1:39:18 AM

Of course Rust is very popular compared to any hobby language (and many non-hobby languages), but that is not the goal it set for itself to be judged by.

by pron

2/15/2026 at 9:58:02 AM

Correct, the goal is to be foster the adoption of safe systems programming, which given the uptake across all major cloud hyperscalers powering the Internet, and all major OS vendors selling hardware (with exception of one because they have their own alternative), is what I would consider a large success of anyone dreaming to get their language adopted at scale.

All major cloud vendors deploying my Java, .NET and nodejs containers do so, in infrastructure that has various layers of Rust code in it.

To value that as mediocre is quite strange.

by pjmlp

2/14/2026 at 3:56:43 PM

> 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.

by metaltyphoon

2/14/2026 at 6:59:22 PM

> It was an overall improvement than those and therefore there is a legit reason for it to take off.

Of course. The rate of adoption is related to the increase in value compared to the status quo, much like how genes spread. But Rust's adoption is slow precisely because its "fitness benefit" is low.

> That would almost always cause problems but for greenfield projects it's a no brainer IMO.

It would have been a no brainer if, when writing a new codebase expected to last 20 years or more (which is often the case with software written in low-level languages), you'd believe the chosen language to be very popular over the next few deacdes. But given its slow adoption compared to languages that ended up achieving that status, despite it's rather old age, it's not looking like a safe bet, which is why Rust's adoption for important greenfield projects is also low (again, relative to other languages).

by pron

2/14/2026 at 8:22:16 PM

> 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.

No, this completely overestimates how quickly languages gain prominence.

C came out in 1972 and didn't gain its current dominance until approximately the release of the ANSI C spec in 1989/1990, after 17 years.

C++ came out in 1985 and didn't become the dominant language for gamedev until the late 90s (after it had its business-language-logic niche completely eaten by Java), after 14 years or so.

Python came out in 1991 and labored as an obscure Perl alternative until the mid-late 2000s, after about 16 years (we can carbon-date the moment of its popularity by looking at when https://xkcd.com/353/ was released).

Javascript came out in 1995 and was treated as a joke and/or afterthought in the broader programming discourse until Node.js came out in 2009, after 14 years.

Rust is currently 11 years old, and it's doing quite excellently for its age.

by kibwen

2/15/2026 at 1:18:02 AM

> C came out in 1972 and didn't gain its current dominance until approximately the release of the ANSI C spec in 1989/1990

While it kept growing in popularity later, by 1983-5 C was already one of the top programming langugages in the world.

> C++ came out in 1985 and didn't become the dominant language for gamedev until the late 90s

Major parts of Windows and Office were being written in C++ in the early-mid 90s, before C++ turned 10. Visual C++, one of Microsoft's flagship development products, came out in 1993. Huge mission-critical, long-term, industrial and defence projects were being written in C++ during or before 1995 (I was working on such a project).

> Python came out in 1991 and labored as an obscure Perl alternative until the mid-late 2000s

Even in 2002 Python was widespread as a scripting language. But it is, indeed, the best and possibly only example of a late bloomer language.

> Javascript came out in 1995 and was treated as a joke and/or afterthought in the broader programming discourse until Node.js came out in 2009

AJAX (popularised by Gmail) pretty much revolutionised the web in 2004. When jQuery came out in 2006, JS was all over the place.

by pron

2/15/2026 at 2:24:40 PM

> Major parts of Windows and Office were being written in C++ in the early-mid 90s, before C++ turned 10.

Major parts of Windows, Android, and Linux were being written in Rust before it turned 10. Major parts of AWS were being written in Rust before it turned 4. Major parts of Dropbox were being written in Rust before it turned 1. So you agree by your own criteria that Rust is a major language?

> While it kept growing in popularity later, by 1983-5 C was already one of the top programming langugages in the world.

In the mid-80s, C still had plenty of major and healthy competitors, as pjmlp will imminently arrive to remind you. By the criteria of mid-80s C, Rust is already one of the top programming languages in the world.

> AJAX (popularised by Gmail) pretty much revolutionised the web in 2004. When jQuery came out in 2006, JS was all over the place.

No, despite the existence and availability of freestanding interpreters (e.g. Rhino), Javascript was an also-ran everywhere except the web; which is to say, nobody was choosing to use Javascript except the people forced at gunpoint to use it. There are infinitely more people choosing to use Rust at the age of 11 than were choosing to use Javascript at the age of 11, which means that, once again, by your criteria, you must consider Rust a major language. You can just admit it instead of being a tsundere.

by kibwen

2/16/2026 at 12:42:54 AM

> So you agree by your own criteria that Rust is a major language?

No, because I was merely responding to your specific points and the extent is nowhere near the same. C++ had a huge market share before it turned 10. In the late nineties I was working on a critical air traffic control system, first used in 1995, written half in Ada half in C++. Around 1995-6 C++ was already ubiquitous in serious software.

> In the mid-80s, C still had plenty of major and healthy competitors, as pjmlp will imminently arrive to remind you.

He doesn't need to remind me because I was there. Yes, there were major competitors, yet C was already very near the top.

> Javascript was an also-ran everywhere except the web

That's pretty much where it is today, yet it's still #1 (if we count TS as part of JS).

> There are infinitely more people choosing to use Rust at the age of 11 than were choosing to use Javascript at the age of 11

The number of people using Rust professionally is a fraction of that of any of the languages we mentioned, plus many more (C#, PHP, Ruby, Go, Kotlin) at the same age. It's more similar to Ada's adoption at that age in size (of course, there wasn't much small OSS projects then at all, let alone written in Ada, but there were many more big, mission- and even safety-critical systems being written in Ada at that age than in Rust). Is it a serious language? Absolutely! But so far its trajectory doesn't resemble that of any language that's achieved wide popularity.

by pron

2/14/2026 at 10:25:45 PM

These languages have origin in a different era, without Reddit, Twitter or HN to spam about them, do we cannot really compare adoption rates.

by wolvesechoes

2/16/2026 at 7:50:10 AM

You can go into Usenet archives, and ads on digital copies from Byte, Computer Shopper, Dr. Dobbs, PC Techniques, The C Users Journal, The C/C++ Users Journal, Your Sinclair, Amiga Format, MicroHobby, Micromania, SoloProgamadores, Spooler,...

And see which compiler toolchains had more ads, articles submissions, or source code listings.

by pjmlp

2/15/2026 at 1:31:21 PM

No, this is silly. You can look at the availability and maturity of toolchains, the rate of release of projects written in that language, the rate of release of books and learning materials, the rate at which universities begin teaching the language, the volume of discourse devoted to that language in magazines and the online venues which did exist (e.g. Usenet), and crucially the declining metrics of all of the above for the direct competitors of that language.

by kibwen

2/14/2026 at 5:49:46 PM

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.

by ceteia

2/14/2026 at 6:41:32 PM

Growing in absolute numbers doesn't mean growing the market share, and even a growing market share is not necessarily sufficiently fast growth to become a safe bet. All languages that ended up becoming very popular grew their market share much faster than Rust does. Being an old language with some real market share is obviously better than being an old language with negligible market share, but being an old language with real, but small, market share is not exactly a sign of confidence.

It's true that the total market share for low level languages (C + C++ + Rust + Zig + others) continues declining, as it has for a couple of decades now (that may change if coding agents start writing everything in C [1] but it's not happening yet), but that's all the more reason to find some "safe bet" within that diminishing total market. Rust's modest success is enough for some, but clearly not enough for many others to be seen as a safe bet.

[1]: https://stephenramsay.net/posts/vibe-coding.html

by pron

2/14/2026 at 7:12:24 PM

Do you know of a good way to measure market share? I know of GitHub's and StackOverflow's surveys, but I'm not sure how well they reflect reality. There is also Redmonk.

GitHub's survey did not say much about Rust I think, despite Rust projects often having lots of starring. Rust projects might have a greater ratio of stars-to-popularity than projects in other languages, though.

StackOverflow's survey was much more optimistic or indicated popularity for Rust.

Redmonk places Rust at place 19th.

by ceteia

2/14/2026 at 8:32:16 PM

The best sources are industry studies by market research companies that collect information from companies. The best public sources, IMO, are those based on job openings (as jobs correlate more with total number of lines of code than sources based on number of repos, PRs, or questions). Some of these are about a year out-of-date:

https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...

https://uk.indeed.com/career-advice/career-development/codin...

https://www.itransition.com/developers/in-demand-programming...

https://www.hackerrank.com/blog/top-developer-skills-in-2025...

Viewing these numbers through an optimistic or pessimistic lens is a matter of perspective and, of course, no one knows the future. But when you compare Rust, which is a middle-aged language now, to how languages that ended up "making it" were at the same age, the comparison is not favourable.

by pron

2/14/2026 at 11:30:48 PM

The first genuinely usable version of Rust was only released in late 2018. Rust is a very new language still.

by zozbot234

2/15/2026 at 1:23:26 AM

Except you could say something similar about the first few years of every language that became very popular, and the comparison would still not be in Rust's favour.

by pron

2/14/2026 at 12:19:51 PM

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.

by cies

2/14/2026 at 2:12:36 PM

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.

by pmarreck

2/14/2026 at 3:34:16 PM

I like that I can easily smell bad Zig by looking at it, but I'm notoriously bad at smelling bad C.

by cies

2/14/2026 at 1:31:40 PM

> 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.

by flohofwoe

2/14/2026 at 1:43:47 PM

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.

by zozbot234

2/14/2026 at 1:48:17 PM

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).

by flohofwoe

2/14/2026 at 1:52:58 PM

"You can inspect types and build new types at compile time" is a key affordance of dependently typed languages.

by zozbot234

2/14/2026 at 5:02:55 PM

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.

by cies

2/14/2026 at 6:41:47 PM

Not all C++ is OOP, and Rust does support OOP as per CS literature, so much so that I have had no issues rewriting Raytracing Weekend tutorial from C++ into Rust, while keeping the same OOP architecture from the tutorial.

by pjmlp

2/14/2026 at 9:31:46 AM

> Both of these are based on userspace stack switching, sometimes called “fibers”, “stackful coroutines”, or “green threads”.

by tosh