Building a shared vision for Async Rust
I admire the passion, but I’m not sure why I would want Rust at all, not just async.When I want memory safety, async-await, I/O performance, easy multithreading, I write C#. When I want performance of CPU bound code, or lots of integration with native libraries/APIs, I write C++. Sometimes I want both in the same software, compile C++ code into a DLL (or shared library on Linux), and consume it from C#.I don’t have experience with Rust in production software, but based on what I know and my limited experience with the language, it’s worse than the above combo. At least for the projects I usually work on.For pieces where performance doesn’t matter too much (often 70-80% of codebase), or for I/O heavy code, or for the stuff that’s in the standard library of .NET (serialization, compression, cryptography, xml, json, zip, etc.), C# is way easier to write and debug than Rust. Tooling is awesome. Even large projects build in seconds i.e. built/test cycle is really fast.For CPU bound or native interop-heavy pieces, C++ is also way easier than Rust. Intel and ARM only support their SIMD intrinsics for C. OS vendors only support their GPU APIs for C (most of them) or C++ (Direct3D). Many libraries I use are only available for C and/or C++. Using C++ for these pieces is the path of least resistance by a large margin, i.e. saves lots of development costs.The interop between the two adds some friction, but not too much, .NET was designed for easy native interop from the very first version. When I want to expose objects instead of [in addition to] just functions, there’re COM interfaces. At least in my experience, usability of C# brings way more profits compared to the losses from the interop across languages.