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

I guess not clear enough to some people.

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

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

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

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.

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.

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.

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

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

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.

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

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.

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.

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.

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

OTOH going from C++ (OO) to Rust (not OO, borrow checker) is a big leap.

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.

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.

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.

I really see no advantage for Zig over Rust after you get past that 2 first two weeks.

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

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

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

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

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.

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.

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

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.

Nothing is forcing you to do that other than it’s easy to add dependencies. I don’t see how zig is much different

My main Zig project will need over 1,000 edits to get it up there :O I've already had Claude spec out the changes required. I'll just have it or Codex or whatever fork itself into one agent per file and bang on it (for the stuff I can't regex myself) ;)

But the IO thing is frankly a good idea. I/O dependency injection, when I've used it in the past, has made testing quite a bit simpler (such as routing any I/O stream into a string to assert on) and the code much easier to reason about. The extra argument is a bit annoying, but that's the price of purity and it's worth it.

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

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.

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

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

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.

    match (0, 1, 2) {
      case (F(), 0, G()) => ...
    }

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?

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.

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.

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)

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