Someone, somewhere (above me, presumably) made a decision. "From now on", they declared, "all our new stuff must be written in Rust".
I'm not sure where they got that idea from. Maybe they've been reading propaganda. Maybe they fell prey to some confident asshole, and convinced themselves that Rust was the answer to their problems.
I don't know what they see in it, to be honest. It's like I always say: it's not a data race, it's a data marathon.
At any rate, I now find myself in a beautiful house, with a beautiful wife, and a lot of compile errors.
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.
Given that I've been programming professionally for over a decade in Python, Perl, Ruby, C, C++, Javascript, Java, and Rust, I'll pick Rust absolutely any time that I want something running that I won't get called at 3 AM to fix. It probably took me 5 times as long to write it as if I did it in Go or Python, but I guarantee it's saved me 10 times as much time I would have otherwise spent triaging, debugging, and running disaster recovery.
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."
vs.
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!
The language ends up doing a random walk via small steps through the design space without a coherent long term vision, because nothing else is feasible.
