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

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?

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.

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

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

So what is your point?

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

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.

It sounds like Zig would benefit from someone like you on the inside, as a member or active contributor, reviewing and participating in the development of the standard library.

Zig is one of my favorite new languages, I really like the cross-compiler too. I'm not a regular user yet but I'm hopeful for its long-term success as a language and ecosystem. It's still early days, beta/dev level instability is expected, and even fundamental changes in design. I think community input and feedback can be particularly valuable at this stage.

I’m confused. The register clobbering is an issue in the compiler, not in the stdlib implementation right? Or are you saying the stdlib has inline assembly in these IO implementations somewhere? I couldn’t find it and I can’t think why you’d need it.

If it’s a compiler frontend-> LLVM interaction bug, I think you are commenting in the spot - it should go in a separate issue not in the PR about io_uring backend. Also, interaction bugs where a compiler frontend triggers a bug in LLVM aren’t uncommon since Rust was the first major frontend other than clang to exercise code paths. Indeed the (your?) fix in LLVM for this issue mentions Rust is impacted too.

I agree with the higher level points about stability and I don’t like Zig not being a safe language in this day and age, but I think your criticism about quality is a bit harsh if your source of this complaint is that they haven’t put a workaround for an LLVM bug.

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.

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

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

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

Oh but it is.

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.

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.

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.

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

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.

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

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

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

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.

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

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.

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

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

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?

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

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.

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

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.

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.

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.

odin - jangafx’s embergen[1]

jai - thekla’s new game, announced but not yet released —- order of the sinking star[2]

[1]: https://jangafx.com/software/embergen

[2]: https://en.wikipedia.org/wiki/Order_of_the_Sinking_Star

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

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

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.

> 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

> Rust will also never replace C or C++ in any meaningful way

Not only do I disagree it never will, I think it's already well on its way to doing exactly that.

> I think Rust and Zig really don't overlap much when it comes to target audience. E.g. if you're attracted to Rust, you'll probably find Zig terrible (and the other way around).

This is ironic since these two crowds are mostly solving the same type of problems. It's just democrats vs republicans type of split, some of it is just for show and philosophical.

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

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.

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

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.

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.

I've been coding in Zig for nearly 2 months straight now.

Or should I say, I've not written a single line of Zig because I've been managing AI's coding in Zig.

Turns out Zig is a fantastic language to "centaur" on. (Reference is to "centaur chess" and which is also sort of becoming a term indicating close code design cooperation with an LLM.)

All of that C code that the LLM trained on ends up helping it work out algorithms in Zig, except that Zig has waaaay more safety guarantees and checks. And is often faster compiled code than the equivalent C, which is astonishing.

> I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different.

The same can be said about Zig's comptime. It's entirely unlike anything C, C++ or Rust has to offer.

> I expect LLMs to be really good at converting C to Zig.

While it's possible to translate C to Zig code - and you don't need an LLM for that, it's a Zig compiler/build-system feature - the result will be quite different from a project that's developed in Zig from the ground up since the translation output wouldn't make use of Zig's unique features (and Zig isn't really unique as 'C translation target', C can also be translated to unsafe Rust, or even to Javascript - see early Emscripten versions).

Also, the 'C compatibility' of Zig is implemented via a separate compiler frontend, Rust toolchains could do exactly the same thing by integrating the Clang frontend into the Rust compiler.