This was recently discussed: https://news.ycombinator.com/item?id=41801124 https://news.ycombinator.com/item?id=41801124 While it is true that Rust is a strict

This was recently discussed: https://news.ycombinator.com/item?id=41801124 https://news.ycombinator.com/item?id=41801124 While it is true that Rust is a strictly superior option for highly concurrent systems code, it still leaves areas where you can make a mistake regarding lock management and other advanced forms of synchronization. In addition to that, .NET as platform is fairly tolerant to misuse and calling the code that is not thread-safe from multiple threads concurrently usually leads to logic bugs or "stop modifying this collection concurrently, please" exceptions but not to catastrophic memory safety issues like it happens in C/C++. You can read more on its low-level memory model here: https://github.com/dotnet/runtime/blob/main/docs/design/specs/Memory-model.md https://github.com/dotnet/runtime/blob/main/docs/design/spec... > The same is true for async, which in C# is also a problem. Now, this one is strictly not true. Async primitives are thread-safe. In Rust, you must synchronize because at the very least you must deterministically deallocate memory used by shared state between the tasks. In C#, this complexity is handled for you by a GC (ironically, you get negative sentiment towards async from people having experienced Python's async or Rust's async complexity, assuming the same applies to C#). In some scenarios, it is also a throughput optimization since it reduces memory contention by not modifying the cachelines shared between the cores, lending itself into better performance on many-core systems - the memory is modified/reclaimed when it's no longer in use, while the actively shared data is placed elsewhere.