Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ziglang.org

Post reply on HN
Print view View original

141–150 of 315 posts

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

#141

Post by vlovich123 »

lukaslalinsky wrote: post #114
BrouteMinou wrote: post #59

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…

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

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.

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

#142

Post by lioeters »

lukaslalinsky wrote: post #114
BrouteMinou wrote: post #59

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…

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

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.

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

#143

Post by lukaslalinsky »

vlovich123 wrote: post #141
lukaslalinsky wrote: post #114

Earlier quoted context omitted.

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

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

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.

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

#144

Post by pmarreck »

maleldil wrote: post #126
tomalbrc wrote: post #80

Earlier quoted context omitted.

Oh but it isn’t.

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

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

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

#145

Post by cies »

pmarreck wrote: post #116
cies wrote: post #81

Earlier quoted context omitted.

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

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

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

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

#146

Post by vlovich123 »

solatic wrote: post #137
zozbot234 wrote: post #129

Earlier quoted context omitted.

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

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

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

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

#147

Post by zozbot234 »

kartoffelsaft wrote: post #140
zozbot234 wrote: post #92

Earlier quoted context omitted.

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

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…

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.

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

#148

Post by Cloudef »

lioeters wrote: post #142
lukaslalinsky wrote: post #114

Earlier quoted context omitted.

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

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…

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

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

#149

Post by kccqzy »

pmarreck wrote: post #144
maleldil wrote: post #126

Earlier quoted context omitted.

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

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

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

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

#150

Post by dom96 »

BrouteMinou wrote: post #59

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…

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.

Post reply on HN