Is It Time to Rewrite the Operating System in Rust?

> When I see syntax like: var array=something[4...$] I don't see security there, all I see is someone pushing the problem further under the carpet, into the runtime. The runtime (whichever one that is) is safe because its behavior is defined by design for all inputs. Yes there could be a bug, but the design is that all inputs should be defined, and doing something for any given input isn't rocket science. Out of bounds array indexes either panic/throw or return empty lists. That can lead to crashes and logic errors, sure, or maybe DOS attacks, but it cannot lead to undefined behavior or remote code execution. That's a world of difference. C and C++ by design expose heaps of undefined behavior to the caller. The tools for detecting UB are imperfect and don't work if the relevant inputs never show up in test cases. Even when veteran C coders develop the techniques and habits that let them write correct C, mistakes tend to show up at the integration points between libraries written by different people with different techniques and habits ( [this video] ).

Wow, tough crowd! I don't know that I -- or anyone that knows me -- would accuse me of "ever-evolving advocacy", but yes, I did see promise in node.js in 2010[1]. And yes, we at Joyent built systems on node.js -- but we also added unprecedented debuggability and observability along the way.[2]. While my views may not be "ever" evolving, they're also not incapable of it: by 2014, it was clear that node.js was diverging from my personal hopes for it -- that it was not going to become suitable for infrastructure software. While this was distressing at the time, I came to view this as a divergence in values -- a realization that I described at length in a talk in 2017.[3] To the matter at hand: yes, I have fallen in love with Rust.[4] Yes, I think it is a good fit for system software.[5] And yes, this has served as a bonding force at Oxide -- but as much (if not more!) for the values that it reflects than for it itself.[6] [1] [link] [2] [link] [3] [link] [4] [link] [5] [this video] [6] [link]

> The reason that C programs often don’t perform as well as an equivalent rust program[1] is that it’s so incredibly hard to do anything at all in C (especially something reliable) that one can usually only do the simplest thing possible and this typically means simple data structures, simple algorithms and arrays Brian Cantrill talks[1] about exactly this: in his C version he was using AVL trees because they are easy to implement, while his Rust version was using B-trees just because he could. And as a result, his naive first attempt in Rust outperformed his long-optimized C code. [1]: [this video]