So Rust it is then, eh? Could work through the kernel module by module to rewrite it in rust, but it'd be a multi-year process (like Firefox's rewrite has been).
For example, the kernel repository for Redox (a written-in-Rust OS project) appears to have 242 usages of the unsafe keyword (including comments bc lazy), out of 18205 lines of Rust source.
You can wrap most unsafe operations to be safe with proper checks, I've done it myself and it's much less than you would expect since a lot of the memory accesses can be made safe trivially.
I would imagine that initially as PoC one can start by implementing a simple module... obviously a small portion of the Rust stdlib and runtime needs to be ported and of course rustc needs to be integrated into the kernel toolchain...
Perhaps someone has done it privately (i.e., without attempting to submit patches back to source)?
I don't think you actually solve any of the really hard kernel problems with your choice of programming language.
The big problems tend to be about hardware support
(all those drivers, all the odd details about different platforms,
all the subtleties in memory management and resource accounting)
In [2] (2013) he expands on that, essentially explaining how well C maps to machine instructions, and how that helps optimise the kernel.
Personally I think Rust maps very well to machine code, and although it doesn't solve design problems, I do think it saves a lot of time debugging the security flaws and bugs that can result from memory bugs.
[1] https://www.infoworld.com/article/3109150/linux/linux-at-25-... [2] https://www.reddit.com/r/programming/comments/1t0gfy/linus_t...
I don't see a strong argument against a memory-safe language, although granted it won't solve architectural and hardware issues. Perhaps the effort to support, say Rust, in the kernel is just not worth the trade-off at this point? Perhaps no one has taken on the mantle for doing so? But I can't see how one can categorically argue against it...
I don’t think it’s far off, at least for vms, tbh.
Yeah that may be a really good upside to VMs, that they enable new OSs to have a more level playing field with the established OSs. Letting the VM layer handle all the messy details of real hardware.
This is not how things work. You don't arrive at changes like this by out-talking Linus. Talk is cheap and Linus is opinionated.
You need to demonstrate that what you want to do is worthwile, i.e. is not only feasible but also provides a payoff that carries the weight of what you're proposing. You also need to be fiercely committed to your idea and to making it happen inside mainline Linux.
In other words, show me the code (and maintain it out-of-tree for some time, tracking upstream changes and gathering support from other developers).
That's one of the main advantages of C - it runs on pretty much everything.
https://fuchsia.googlesource.com/garnet/+/HEAD/public/rust/c...
I think Nim belongs with D here. You can freely disable the GC in Nim.
Full disclosure: I'm a Nim core dev.
Even current operating systems use forms of garbage collection (such as refcounting) to track resources.
* Boxing anything you take a reference directly to
* Forbidding sum types and complicating the GC to allow interior pointers
* Forbidding references to value types
* A borrow checker
Guess which one is most flexible, and novel in Rust.
We only don't have it thanks to Compaq killing the project after acquiring DEC Olivetti. Politics as usual.
Rust ideas come from Cyclone and ATS, it is not novel in Rust.
The borrow checker still is pretty much WIP, that the NLL changes will surely improve, but don't not yet solve all ergonomic problems.
Cyclone and ATS do not have Rust's combination of ownership and borrowing.
And if both languages have GC, then you're in even more trouble.
The multiple GCs in a process issue is usually due to the collector not playing nice with signal/exception handler installation when using safepoints, which is purely an issue of lazy implementations. There's even ways to collect cross-heap cycles when working this multiple GCs (Xamarin on Android does this fairly well).
Which should just use controlled types, pools or standard containers.
Also there are a few open experiments with Ada,
https://github.com/Lucretia/bare_bones
Then there are the commercial ones used in the industry, making use of bare metal profiles like Ravenscar.
I agree with this. But just saying Firefox has X millions of lines of code doesn't say anything about the possibility for Linux to be ported to Rust.
I never said that. My whole premise is that you can't say anything like this by just saying code count on two very different projects. Maybe you didn't read my comments properly.
> It replaces approximately 160,000 lines of C++ with 85,000 lines of Rust.
https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-I...