Is there a summary of this hour-long video?
Some history of OSes, a bit about Rust. Is it worth re-writing the OS? No, but what about incorporating Rust into OSes, instead of creating a new one from whole cloth? There’s three approaches: in the kernel? Probably not worth it. In userland? Probably worth it. For firmware? Probably worth it.
https://lobste.rs/s/qz9d82/is_it_time_rewrite_operating_syst...
Overall I was sort of disappointed in this video. I would rather hear about someone writing their OWN code in Rust. I watched one of Cantrill's previous talks about this which I liked, so I watched this one too.
It's not that interesting to hear "well Rust has problems for MY domain (kernels), but OTHER people should write their code in Rust (user services and firmware).
There's an obvious asymmetry there, because you know all about the problems in your own domain, but you're less familiar with the problems of other domains (e.g. ones that require a lot of async code, a lot of text parsing, etc.)
-----
I just watched this video. I liked the part about failed C++ operating systems from the early 90’s (Apple’s Copland, an effort from Sun, and Taligent).
Overall he’s excited by Rust, but points out some problems with using it for kernel development:
- Multiply-owned data structures are all over Unix kernels, and Rust’s ownership system doesn’t like those. (i.e. the doubly linked list problem)
- Rust doesn’t allow you to handle memory allocation failure. This is being worked on? I didn’t know this about Rust and it seems odd for a low level language.
He says that instead of kernel development, Rust could be used for:
- user-level services like systemd, or
- firmware.
This doesn’t seem like anything more than a wish though. I don’t see that Rust really shines in those areas.
- I think you could probably write systemd in Go. I don’t see that Rust has any advantage there. Whereas a kernel in Go has some obvious downsides (I know it’s been tried).
- Rewriting firmware in Rust sounds nice, but I don’t think vendors will do it. They have enough problems writing decent C, and they don’t write open source code. He is wishing for them to write Rust and release it as open source, but I’m not optimistic about either of those things.
I think the kernel and the browser are where Rust is interesting – when you need both performance and memory safety. I’m not really excited about Rust for other applications like web services, i.e. doing the job that Go, Python, or Ruby can do. So it does seem unfortunate that there are still some open problems with using Rust for the kernel.
He also points out the many nascent Rust OSes kernels, and the fact that they are “from scratch” systems, i.e. not compatible. I agree that you need a compatible kernel to have any hope of adoption.
The standard library panics upon allocation failure, but allocation is a library thing, not a language thing. You can handle failure if you do it yourself. Eventually we have a path forward to handling it for those data structures too, but we’re not quite there yet.
This wasn’t a big concern because when you’re doing OS level stuff you’re generally not using the standard library anyway.
Although on second thought, I guess you can handle it because it's an exception rather than a panic. But exceptions have other downsides so people don't use them in that domain.
With a lot of low-level operations, go may have issues with mapping its threads to native. I can't remember which kernel interface was it, (there was a post about it on HN) but you have to call it for the same object from the same system thread. Since go didn't guarantee the mapping, you could randomly fail there.