https://www.linkedin.com/feed/update/urn:li:activity:7407863...
BTW in a comment he mentioned that Rust offers concurrency safety. Can someone elaborate on the concurrency model of Rust? I completed the xv6 lock lab a few days ago and it was one of the most difficult labs. Hard to debug and easy to mess up.
epic games' language in development is referenced here in this presentation
https://youtu.be/VBT0j14rn5cI think Rust's concurrency safety (e.g. async on a single thread) is mostly granted by the Pin trait [1], and the async code-gen making sure lifetimes make sense over .await points (which requires things to be either pinned across those points, or to not care about their location in memory potentially moving).
Thread safety is instead given by a couple of auto-derived marker traits, called Send and Sync [2], that denote which kinds of data can be sent or shared between threads safely.
This is coupled with types like Arc, Mutex, etc that can wrap data that isn't safe to share, so that the wrapped data as a whole is safe to share. It is also coupled with functions (like std::thread::spawn [3] and MPSC's send()) that have a requirement for the data to either be Sync/Send, or to take full ownership of it (which ensures there are no other active references to it).
[1] https://doc.rust-lang.org/std/pin/struct.Pin.html
Galen Hunt Author
Distinguished Engineer at Microsoft
3d
@Sukesh Ashok Kumar No memory safety. No concurrency safety. Of course, for a single C or C++ code base, these qualities can be achieved with extraordinary discipline and effort--and lost with just a single mistake. With Rust, can be proven by the compiler.Or rather, it gives abstractions so that higher-level types in stdlib and other libraries can prevent such access. The low-level implementation of the Mutex/etc types themselves do the same thing C and C++ do, via unsafe blocks, atomic primitives, fences, etc.
Update in the HN thread: https://news.ycombinator.com/item?id=46360955
andsoitis•1mo ago