5 ms·

The ergonomics of unsafe rust are abysmal. It would have been 10 times better if they just let you do inline C instead.

by cakealert 1y ago

surajrmal 1y ago
Do you have some examples of what's bad about the ergonomics?
- cakealert 1y ago
  Almost everything. Can't even do pointer arithmetic without x.add() and x.offset()
- vlovich123 1y ago
  https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ https://news.ycombinator.com/item?id=41944121 https://news.ycombinator.com/item?id=41944121 The TLDR is that there’s all sorts of invariants that the Rust compiler internals assume about Rust code (eg pointers don’t alias). In C such assumptions can’t be made. Unsafe rust requires you to uphold all the same invariants that safe rust does without any guardrails and it has more such assumptions than C. C however is uniformly dangerous - there isn’t a safe subset to write your code in. One example would be that you could have something like: let x = 5; do_something(&x as *const _ as *mut _); Now do_something might dereference and write to the pointer. Now you have non-local safety to reason about because if the compiler realizes you’ve tried to dereference a mutable pointer to an immutable variable it’s free to declare that UB and do bad unsound things (the non-locality is because the unsafe is inside do_something but the problem is with the pointer cast in safe rust). There’s all sorts of subtle things like that.
  - zozbot234 1y ago
    > The TLDR is that there’s all sorts of invariants that the Rust compiler internals assume about Rust code (eg pointers don’t alias). There are fairly straightforward ways to disclaim these invariants to a greater or lesser extent as appropriate, such as accepting &Cell<T> arguments (or even, e.g. Option<&Cell<T>>) in lieu of &mut T. But the Rust standard library is not yet comprehensively built with this in mind, so this might be an area where Zig's library facilities have a real advantage unless an effort is made to address this gap.

The ergonomics of unsafe rust are abysmal. It would have been 10 times better if they just let you do inline C instead.

surajrmal 1y ago

Do you have some examples of what's bad about the ergonomics?

cakealert 1y ago
Almost everything. Can't even do pointer arithmetic without x.add() and x.offset()
vlovich123 1y ago
https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ https://news.ycombinator.com/item?id=41944121 https://news.ycombinator.com/item?id=41944121 The TLDR is that there’s all sorts of invariants that the Rust compiler internals assume about Rust code (eg pointers don’t alias). In C such assumptions can’t be made. Unsafe rust requires you to uphold all the same invariants that safe rust does without any guardrails and it has more such assumptions than C. C however is uniformly dangerous - there isn’t a safe subset to write your code in. One example would be that you could have something like: let x = 5; do_something(&x as *const _ as *mut _); Now do_something might dereference and write to the pointer. Now you have non-local safety to reason about because if the compiler realizes you’ve tried to dereference a mutable pointer to an immutable variable it’s free to declare that UB and do bad unsound things (the non-locality is because the unsafe is inside do_something but the problem is with the pointer cast in safe rust). There’s all sorts of subtle things like that.
- zozbot234 1y ago
  > The TLDR is that there’s all sorts of invariants that the Rust compiler internals assume about Rust code (eg pointers don’t alias). There are fairly straightforward ways to disclaim these invariants to a greater or lesser extent as appropriate, such as accepting &Cell<T> arguments (or even, e.g. Option<&Cell<T>>) in lieu of &mut T. But the Rust standard library is not yet comprehensively built with this in mind, so this might be an area where Zig's library facilities have a real advantage unless an effort is made to address this gap.