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

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

by Retro_Dev • 5 months ago

369 230 5 months ago

tosh• 5 months ago

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

khalic• 5 months ago

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

BrouteMinou2• 5 months ago

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.

pygy_• 5 months ago

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.

warent• 5 months ago

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

eptcyka• 5 months ago

Oh but it is.

flohofwoe6• 5 months ago

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.

pron12• 5 months ago

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

epolanski2• 5 months ago

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.

radarroark• 5 months ago

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.

dxdm• 5 months ago

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.

pmarreck9• 5 months ago

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

PaulRobinson• 5 months ago

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.

wiseowise• 5 months ago

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.

lukaslalinsky6• 5 months ago

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.

vlovich1239• 5 months ago

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.

lioeters• 5 months ago

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.

steeve• 5 months ago

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.

rererereferred• 5 months ago

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

BrouteMinou2• 5 months ago

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.

solatic3• 5 months ago

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.

zozbot23412• 5 months ago

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

ozgrakkurt5• 5 months ago

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.

wolvesechoes6• 5 months ago

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.

DetroitThrow2• 5 months ago

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.

dom96• 5 months ago

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.

DetroitThrow2• 5 months ago

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!

srcreigh2• 5 months ago

Please stop posting 0-information-content complaints.

pstuart• 5 months ago

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.

crest• 5 months ago

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

ksec• 5 months ago

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.

jauntywundrkind• 5 months ago

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.

hxtk2• 5 months ago

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.

melodyogonna• 5 months ago

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

pjmlp28• 5 months ago

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.

audunw2• 5 months ago

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

xnoreq• 5 months ago

Huh? Golang doesn't have async?!

epolanski2• 5 months ago

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.

bastawhiz2• 5 months ago

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.

allthetime4• 5 months ago

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

spacechild1• 5 months ago

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

lukaslalinsky6• 5 months ago

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.

hu35• 5 months ago

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.

lukaslalinsky6• 5 months ago

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

audunw2• 5 months ago

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.

lukaslalinsky6• 5 months ago

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.

nesarkvechnep• 5 months ago

I’m waiting for the kqueue implementation.

small_model• 5 months ago

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.

cies3• 5 months ago

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.

flohofwoe6• 5 months ago

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.

pmarreck9• 5 months ago

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.

testdelacc1• 5 months ago

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.

allthetime4• 5 months ago

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.

pron12• 5 months ago

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

metaltyphoon2• 5 months ago

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…

ceteia6• 5 months ago

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.

zozbot23412• 5 months ago

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.

kartoffelsaft2• 5 months ago

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.

flohofwoe6• 5 months ago

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

sgt2• 5 months ago

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.

junon3• 5 months ago

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.

pmarreck9• 5 months ago

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

wolvesechoes6• 5 months ago

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

pjmlp28• 5 months ago

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.

Quothling3• 5 months ago

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.

pjmlp28• 5 months ago

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

Cloudef2• 5 months ago

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

up2isomorphism• 5 months ago

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

srcreigh2• 5 months ago

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

portly• 5 months ago

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.

derefr2• 5 months ago

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

hu35• 5 months ago

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

So what is your point?

beAbU• 5 months ago

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

Klonoar• 5 months ago

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.

allthetime4• 5 months ago

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.

dan-robertson• 5 months ago

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?

travisgriggs• 5 months ago

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.

cbmuser3• 5 months ago

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.

yxhuvud• 5 months ago

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.

reppap• 5 months ago

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.

ekipan• 5 months ago

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.

Seattle35032• 5 months ago

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.

pjmlp28• 5 months ago

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:

Seattle35032• 5 months ago

Fair enough

bastawhiz2• 5 months ago

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.

allthetime4• 5 months ago

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.

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

Related Stories