4 ms·

You're missing that Rust has safety in terms of multithreading, which C# doesn't have. Writing a data race in C# is the default, writing thread safe code takes

You're missing that Rust has safety in terms of multithreading, which C# doesn't have. Writing a data race in C# is the default, writing thread safe code takes work. In Rust, the default is that it's safe, you have to jump through a lot of hoops to try to make it not thread safe. The same is true for async, which in C# is also a problem. In all C# codebases I've seen, you have threads and tasks, and you often run into multiple threads or tasks holding a mutable reference to the same data. That's not legal in Rust without synchronization/locking. If you don't believe me, just spin up a new main.rs file and write code that has a data race.

neonsunset 2y ago
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.
throwawaymaths 2y ago
Easy. Decide to use an ecs system because of its lower memory footprint. Pass around integer indices. Use two threads. Data race.
- lionkor 2y ago
  That seems like a lot more effort than in C#

neonsunset 2y ago

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.

throwawaymaths 2y ago

Easy. Decide to use an ecs system because of its lower memory footprint. Pass around integer indices. Use two threads. Data race.

lionkor 2y ago
That seems like a lot more effort than in C#