4 ms·
Here's my summary from 2 months ago: https://lobste.rs/s/qz9d82/is_it_time_rewrite_operating_system_rust#c_gnp1gb https://lobste.rs/s/qz9d82/is_it_time_rewrite
by chubot 8y ago
Here's my summary from 2 months ago:
https://lobste.rs/s/qz9d82/is_it_time_rewrite_operating_system_rust#c_gnp1gb 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.
- steveklabnik 8y ago> 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. 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.
- chubot 8y agoOK, thanks for the clarification. C++ also has this issue, because vector<> and so forth can raise std::bad_alloc. So AFAIK basically nobody who writes kernels in C++ uses STL. 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.
- steveklabnik 8y agoNo problem. And yeah, it’s effectively the same. You can catch panics if you really need to, but it’s certainly not idiomatic generally. (And most OS-level code makes them aborts which cannot be caught.) This is a situation where it would be... fine. Not as nice as making the api fallible from the start.
- anp 8y agoI could have sworn std aborted on allocation failure, not panicked. Am I misremembering?
- steveklabnik 8y agoAh yes, my bad https://github.com/rust-lang/rust/issues/26951 https://github.com/rust-lang/rust/issues/26951
- viraptor 8y ago> I think you could probably write systemd in Go. I don’t see that Rust has any advantage there. 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.