I was given the task to learn Rust and write a report on the fitness for Zircon. The internal doc colloquially known as "2016 cpu's Rust trip report" remained very popular for years in that did not made me very popular with with the (then nascent) internal Rust community.
This was Feb 2016 so even a year later the doc was already outdated in many places, and that was a telling symptom: even though Rust 1.0 was released 6 months earlier, it felt very much 'in progress'.
More than that. Languages like C++ grow in spurts, Rust back then was in constant acceleration.
I was using a couple of 'bare metal' Rust projects to prototype and play with it and both became unusable mere weeks later.
The second factor is critical body mass. Not only we needed to get proficient on a fast moving language but we needed to have trained reviewers. When the reviewer knows less about good patterns/practices than the person writing the code, badness ensues.
Rust might have solved some safety issues but I am pretty sure does not solve (code) monkey at the wheel problem.
The third factor is how little of the ergonomics remained without the standard library. A lot would have to be re-written.
The thing with C is to quote Bane, it was born in bare metal, Rust merely adopted it.
yes, yes, things are much better now. calm down.
Then there are the smaller companion horrors, for example, 'the' key data-structure of a kernel is the linked list, for reasons too messy to explain here, you don't really want to change that.
In Rust the linked list is the most convoluted thing and if you listen carefully the language is whispering "don't use that, it makes me sad".
In conclusion. Too early, lack of experts, rapid evolution pains.
It was stacking risk on top of an already risky project.
• • •
Missing some Tweet in this thread? You can try to
force a refresh