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

171–180 of 315 posts

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

#171

Post by zozbot234 »

phicoh wrote: post #167
kartoffelsaft wrote: post #140

Earlier quoted context omitted.

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…

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

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.

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

#172

Post by wolvesechoes »

pmarreck wrote: post #113
small_model wrote: post #78

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.

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…

> 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

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

#173

Post by cies »

flohofwoe wrote: post #99
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 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 differ…

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.

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

#175

Post by phicoh »

zozbot234 wrote: post #171
phicoh wrote: post #167

Earlier quoted context omitted.

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

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…

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.

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

#176

Post by srcreigh »

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…

Please stop posting 0-information-content complaints.

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

#177

Post by sgt »

zozbot234 wrote: post #124
sgt wrote: post #109

Earlier quoted context omitted.

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

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…

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.

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

#178

Post by junon »

flohofwoe wrote: post #94
small_model wrote: post #78

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.

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

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

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

#179

Post by maleldil »

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.

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

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

#180

Post by zozbot234 »

phicoh wrote: post #175
zozbot234 wrote: post #171

Earlier quoted context omitted.

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…

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.

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.
Post reply on HN