3 ms·

Rust is still changing so much that this would be a very unsafe bet for maintainability. Plus you would absolutely have to use a whole shitload of `unsafe` for

Rust is still changing so much that this would be a very unsafe bet for maintainability. Plus you would absolutely have to use a whole shitload of `unsafe` for optimization, rendering all the advantages of Rust pointless.

steveklabnik 4y ago
Rust is not changing in a backwards incompatible way, and hasn't been for the past seven years. You don't need as much unsafe as you think, especially for "optimization."
linkdd 4y ago
I'd recommend reading https://os.phil-opp.com/ https://os.phil-opp.com/ to drive away those wrong assumptions.
- ActorNightly 4y ago
  Writing an OS for education/research is MUCH different than writing an OS for general use.
  - linkdd 4y ago
    And in both cases: Rust is still backward compatible (old code will compiles on newer compiler versions) so you won't be rewriting what already works. You won't use unsafe that much (especially once the hardware parts have been abstracted), see the link I gave you as proof. The advantages of Rust are not pointless: - the type system - the ownership/borrowing/move semantics - the ecosystem - the build system - the way you can contain the memory-unsafe parts in a small/controlled API Fuschia and RedoxOS are very much not "research projects" and they manage very well their code maintainability.
    - ActorNightly 4y ago
      Fuschia is based on the Zircon kernel, and Im going to let you take a guess on which language Zircon is written in (hint, its not Rust). Just to clarify, when I say the OS, Im going with the definition of Linux Kernel being the actual OS, with other stuff on top of it comprising the rest of the system. The core kernel should absolutely be written in C, with careful attention to detail. The rest of the OS is totally fine to use Rust (or really any other language). Which is pretty much the direction Linux is going. The core kernel will still use C because its the most stable syntax currently in existence, while module development will allow Rust. There has been efforts to write drivers in Rust for things like NVME (https://www.phoronix.com/news/LPC-2022-Rust-Linux https://www.phoronix.com/news/LPC-2022-Rust-Linux), which required a lot of work, and guess what, plenty of `unsafe` scattered through the implementation. Yes, it made the implementation easier, but that is one of the major problems. As long as Rust allows this, you won't have safe code. And without it, things will take much longer to write, likely be slower without careful design, which means less adoption. Its a Catch 22 really, since less adoption means less development, but nevertheless, getting rid of unsafe is absolutely necessary if you want Rusts safety features to work. Also to address your advantages of Rust, C has a type system, its just is very open and has less semantics (as it should, so that the software doesn't do its ow aren't clearly stated by the developer). It also has an ecosystem (LLVM/Clang, GCC, libc, all the standard libraries in the linux kernel). You generally also don't want a package manager for something that you write an OS in, considering all the exploits that happen with pip/npm and malicious packages. C also has a very good build system (CMake/Scons), and plenty of memory safety built into core functions.
oconnor663 4y ago
Steve has already commented re: stability. Personally I've maintained some Rust libraries for several years, and I don't think I've ever seen a build break because of a toolchain update on a tier 1 platform. (I did see a break on 32-bit ARM that made me use nightly for a few weeks several years ago.) Re: unsafe, there's a similar objection/question that comes up frequently. The Rust standard library is full of unsafe code, as are a lot of common foundational crates. Doesn't that mean that most Rust applications are vulnerable to memory corruption bugs? The short answer is that safety in Rust isn't about having proofs of correctness all the way down. (Some people do that, but they're inscrutable wizards, and I try not to meddle in their affairs.) Instead, it's about having robust and useful ways to encapsulate unsafety. You want to be able to say "if this function is correct, then callers can't use it to corrupt memory no matter how hard they try." Rust gives you ways to achieve that, without paying the cost of a garbage collector or a GIL. In embedded/OS development, the difference is that the big pile of unsafe code underneath is probably written by you instead of by compiler folks. That certainly isn't easy. But the tools for encapsulating it are the same, and the value proposition is the same.

steveklabnik 4y ago

Rust is not changing in a backwards incompatible way, and hasn't been for the past seven years. You don't need as much unsafe as you think, especially for "optimization."

linkdd 4y ago

I'd recommend reading https://os.phil-opp.com/ https://os.phil-opp.com/ to drive away those wrong assumptions.

ActorNightly 4y ago
Writing an OS for education/research is MUCH different than writing an OS for general use.
- linkdd 4y ago
  And in both cases: Rust is still backward compatible (old code will compiles on newer compiler versions) so you won't be rewriting what already works. You won't use unsafe that much (especially once the hardware parts have been abstracted), see the link I gave you as proof. The advantages of Rust are not pointless: - the type system - the ownership/borrowing/move semantics - the ecosystem - the build system - the way you can contain the memory-unsafe parts in a small/controlled API Fuschia and RedoxOS are very much not "research projects" and they manage very well their code maintainability.
  - ActorNightly 4y ago
    Fuschia is based on the Zircon kernel, and Im going to let you take a guess on which language Zircon is written in (hint, its not Rust). Just to clarify, when I say the OS, Im going with the definition of Linux Kernel being the actual OS, with other stuff on top of it comprising the rest of the system. The core kernel should absolutely be written in C, with careful attention to detail. The rest of the OS is totally fine to use Rust (or really any other language). Which is pretty much the direction Linux is going. The core kernel will still use C because its the most stable syntax currently in existence, while module development will allow Rust. There has been efforts to write drivers in Rust for things like NVME (https://www.phoronix.com/news/LPC-2022-Rust-Linux https://www.phoronix.com/news/LPC-2022-Rust-Linux), which required a lot of work, and guess what, plenty of `unsafe` scattered through the implementation. Yes, it made the implementation easier, but that is one of the major problems. As long as Rust allows this, you won't have safe code. And without it, things will take much longer to write, likely be slower without careful design, which means less adoption. Its a Catch 22 really, since less adoption means less development, but nevertheless, getting rid of unsafe is absolutely necessary if you want Rusts safety features to work. Also to address your advantages of Rust, C has a type system, its just is very open and has less semantics (as it should, so that the software doesn't do its ow aren't clearly stated by the developer). It also has an ecosystem (LLVM/Clang, GCC, libc, all the standard libraries in the linux kernel). You generally also don't want a package manager for something that you write an OS in, considering all the exploits that happen with pip/npm and malicious packages. C also has a very good build system (CMake/Scons), and plenty of memory safety built into core functions.

oconnor663 4y ago

Steve has already commented re: stability. Personally I've maintained some Rust libraries for several years, and I don't think I've ever seen a build break because of a toolchain update on a tier 1 platform. (I did see a break on 32-bit ARM that made me use nightly for a few weeks several years ago.) Re: unsafe, there's a similar objection/question that comes up frequently. The Rust standard library is full of unsafe code, as are a lot of common foundational crates. Doesn't that mean that most Rust applications are vulnerable to memory corruption bugs? The short answer is that safety in Rust isn't about having proofs of correctness all the way down. (Some people do that, but they're inscrutable wizards, and I try not to meddle in their affairs.) Instead, it's about having robust and useful ways to encapsulate unsafety. You want to be able to say "if this function is correct, then callers can't use it to corrupt memory no matter how hard they try." Rust gives you ways to achieve that, without paying the cost of a garbage collector or a GIL. In embedded/OS development, the difference is that the big pile of unsafe code underneath is probably written by you instead of by compiler folks. That certainly isn't easy. But the tools for encapsulating it are the same, and the value proposition is the same.