[nn3]

>Well of course it's not surprising, with memory safety as one of its goals.

Where is this idea coming from that memory safety has to be complicated? Nearly all languages (basically everything except C/C++/Assembler) people are using are memory safe. And usually it's not complicated at all.

[untog]

Well Rust's complication is memory safety and the lack of garbage collector. You see similar issues in a language like Swift, but Swift lets you create a memory leak very easily if you're not aware of the issues. Which can be fine when you're just starting out, you can always learn about it later. But Rust isn't so charitable: you must learn about memory safety upfront. The plus side is that it's significantly more difficult to accidentally create a memory leak.

[dilap]

I've only played with Rust a little bit, but I think something that often goes under-remarked is that its ownership system doesn't just give you "static GC" -- it also guarantees no data races for multithreading. This is pretty awesome.

[mratsim]

> no data races for multithreading

This is simply not true. Rust borrow checker has no notion of memory models: i.e. sequential consistency, acquire, release or relaxed semantics.

The Tokio team needs an additional model checker to ensure no data race in Tokio:

- https://github.com/tokio-rs/loom

If you want to ensure no data races you need formal verification not a borrow checker, I've compiled my research and a RFC for Nim formal verification here:

- https://github.com/mratsim/weave/issues/18

- https://github.com/nim-lang/RFCs/issues/222