Is It Time to Rewrite the Operating System in Rust?

What Hacker News said

Recommends equalunique · 2019-05 · on “GKE Sandbox: Independent operating system kernel to each container”

My introduction to gVisor was the talk by Emma Haruka Iwao at InfoQ NY 2018: [LINK] I learned of the talk because Brian Cantrill referenced it during his very deep dive into operating systems, C, and Rust given later at the some event: [this video]

Cites oconnor663 · 2019-07 · on “D as a C Replacement”

> 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 behavio

Cites 1MachineElf · 2020-06 · on “The Beauty of Unix Pipelines”

I only linked that because most people don't know what B is, and I suppose the difference between "innovation meant to fill the space" and "extention" wasn't so important to me. My source for the claim itself is from 14m30s of Brian Cantrill's talk "Is It Time to Rewrite the Opersting System in Rust" [this video]

Cites bcantrill · 2020-09 · on “Rust is not a good C replacement (2019)”

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:

Cites littlestymaar · 2021-01 · on “Rust is now overall faster than C in benchmarks”

> 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]

Cites oconnor663 · 2023-02 · on “Why I Use C When I Believe in Memory Safety”

Bryan Cantrill making a similar point: [this video] > I can write C that frees memory properly...that basically doesn't suffer from memory corruption...I can do that, because I'm controlling heaven and earth in my software. It makes it very hard to compose software. Because even if you and I both know how to write memory safe C, it's very hard for us to have an interface boundary where we can agree about who does what.