Remix.run Logo
zozbot234 3 hours 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.

kartoffelsaft 37 minutes ago | parent [-]

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.

zozbot234 28 minutes ago | parent [-]

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.