I wrote a bespoke time-series database in Rust a few years ago, and it has had exactly one issue since I stood it up in production, and that was due to pessimistic filesystem access patterns, rather than the language. This thing is handling hundreds of thousands of inserts per second, and it's even threaded.
Because lower-level software has more operational constraints than higher-level software (e.g. it typically cannot tolerate a runtime or memory management via garbage collection), developing a memory safe language suitable for systems software is particularly challenging. The Rust language has met that challenge, however, and is an excellent candidate for replacing C in many systems applications.
We plan to invest in the tools that allow systems engineers to move their software to Rust. This means investing in improving package management, compilers, and Foreign Function Interface (FFI) generators. In many cases this will include providing interfaces compatible with existing widely-used components to enable transition. With these tools, adoption of a memory safe alternative will scale much faster without replication of efforts.
Mutex: "Mom says it's my turn on the synchronization primitive."
Write lock: "Hey! You all are not allowed to look until I'm done writing!"
Read lock: "Hey! You are not allowed to edit what you wrote until we're done reading it!"
Thanks for an actual 5 year old reply, made me laugh
… [ergonomics] is a downstream symptom, whereas the inclusivity thing is the upstream driver for all of that. So that's where you get ergonomics, right? If you don't care about inclusivity for beginners and whatever, then you're not going to care about that.
The long compile times where all responsibility is taken away from you is infinitely more effective than submission patterns in BDSM, where the graceful rustc takes over and all you have to do is wait until they tell you that you're a good person and that everything is alright!