4 ms·

If you want more convenience from Rust and do not want to mess with Rust borrow checker, you do not really have to switch to Swift: you can rely on Rust referen

If you want more convenience from Rust and do not want to mess with Rust borrow checker, you do not really have to switch to Swift: you can rely on Rust reference counting. Use 1.) Rust reference-counted smart pointers[1] for shareable immutable references, and 2.) Rust internal mutability[2] for non-shareable mutable references checked at runtime instead of compile time. Effectively, you will be writing kind of verbose Golang, but keep Rust expressiveness. [1] https://doc.rust-lang.org/book/ch15-04-rc.html https://doc.rust-lang.org/book/ch15-04-rc.html [2] https://doc.rust-lang.org/book/ch15-05-interior-mutability.html https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...

rjh29 8mo ago
It gets really verbose though!
- virtualritz 8mo ago
  > It gets really verbose though! Nope, you just use wrapper types (which you should anyway).
Cyph0n 8mo ago
Also, you get the ability to use Rc (non-atomic refcount) as long as you’re not in a multithreaded env. The atomic version is Arc, which is similar to C++ shared_ptr. And there are no footguns to using Rc. More specifically, you cannot mistakenly use a Rc across threads, because the compiler will ensure that you aren’t doing this thanks to the Send marker trait.
torginus 8mo ago
Oh god, I hope I read this wrong. I thought Rust finally fixed C/C++'s worst issue which is aliasing, which means that if you pass a struct by pointer to a function, since any number of other mutable references might exist to it, the only correct way to treat it, is to reload/save it to memory every time you access it. This is obviously unacceptable from a performance point, so compilers have resorted to heavy static analysis, and a bunch of hacks to prove nobody else is actually writing to that memory. These hacks were brittle, leading to buggy or slow code, which is why C introduced the __restrict__ keyword, that allowed the programmer to tell the compiler that nobody is going to write to said variable, which meant it was now the programmer's responsibility to enforce that. High-perf code is littered with it. I thought Rust's ownership system prevented mutable aliases, thus it allowed the compiler to automatically tag every pointer with __restrict__ , but if what the article says is right, Rust is bad as C/C++, because there are 1% exceptions to the general rule the compiler enforces.
- steveklabnik 8mo ago
  Rust tags every &mut T and every &T with the equivalent of restrict except for when the T transitively contains an UnsafeCell<T>. Types like Arc<T> and Rc<T> are built on top of UnsafeCell<T>. Don’t use shared ownership? You get the semantics you want. It’s the norm for the vast majority of things.
  - torginus 8mo ago
    Thanks for the answer, that sounds reassuring. I have another question, from what you said, it sounds like you remove restrict from the whol argument, but technically, afaict, the Rust borrow rules still prevent anything inside those structs getting aliased, with the exception of the stuff inside UnsafeCell<> (even with Rc<> the underlying value cannot be aliased, only the reference counter). Does Rust/LLVM track aliasing to this degree, or is it all or nothing, like if you have a UnsafeCell anywhere, the whole type is excluded from restrict?
    - steveklabnik 8mo ago
      I am not sure off the top of my head, to be honest. https://news.ycombinator.com/item?id=46616616 https://news.ycombinator.com/item?id=46616616 was a thread where I was talking about this sort of thing previously, you could probably adapt those code examples and get an answer.

rjh29 8mo ago

It gets really verbose though!

virtualritz 8mo ago
> It gets really verbose though! Nope, you just use wrapper types (which you should anyway).

Cyph0n 8mo ago

Also, you get the ability to use Rc (non-atomic refcount) as long as you’re not in a multithreaded env. The atomic version is Arc, which is similar to C++ shared_ptr. And there are no footguns to using Rc. More specifically, you cannot mistakenly use a Rc across threads, because the compiler will ensure that you aren’t doing this thanks to the Send marker trait.

torginus 8mo ago

Oh god, I hope I read this wrong. I thought Rust finally fixed C/C++'s worst issue which is aliasing, which means that if you pass a struct by pointer to a function, since any number of other mutable references might exist to it, the only correct way to treat it, is to reload/save it to memory every time you access it. This is obviously unacceptable from a performance point, so compilers have resorted to heavy static analysis, and a bunch of hacks to prove nobody else is actually writing to that memory. These hacks were brittle, leading to buggy or slow code, which is why C introduced the __restrict__ keyword, that allowed the programmer to tell the compiler that nobody is going to write to said variable, which meant it was now the programmer's responsibility to enforce that. High-perf code is littered with it. I thought Rust's ownership system prevented mutable aliases, thus it allowed the compiler to automatically tag every pointer with __restrict__ , but if what the article says is right, Rust is bad as C/C++, because there are 1% exceptions to the general rule the compiler enforces.

steveklabnik 8mo ago
Rust tags every &mut T and every &T with the equivalent of restrict except for when the T transitively contains an UnsafeCell<T>. Types like Arc<T> and Rc<T> are built on top of UnsafeCell<T>. Don’t use shared ownership? You get the semantics you want. It’s the norm for the vast majority of things.
- torginus 8mo ago
  Thanks for the answer, that sounds reassuring. I have another question, from what you said, it sounds like you remove restrict from the whol argument, but technically, afaict, the Rust borrow rules still prevent anything inside those structs getting aliased, with the exception of the stuff inside UnsafeCell<> (even with Rc<> the underlying value cannot be aliased, only the reference counter). Does Rust/LLVM track aliasing to this degree, or is it all or nothing, like if you have a UnsafeCell anywhere, the whole type is excluded from restrict?
  - steveklabnik 8mo ago
    I am not sure off the top of my head, to be honest. https://news.ycombinator.com/item?id=46616616 https://news.ycombinator.com/item?id=46616616 was a thread where I was talking about this sort of thing previously, you could probably adapt those code examples and get an answer.