Is it me (and have I been hiding/asleep under a rock for a long time) or is Linus' tone vastly (and pleasantly) different from what his previous persona is known to be?
I actually loved (I mean really loved) reading the response as it not only was encouraging but also highly respectful and almost glowing with a trained sort of nuance! Just wow!
Even for normal user space code having a way to detect panic at compile time and abort compilation would be great. Ideally together with a way to wrap functions that do panic by catching it and throwing an error instead so the panic infrastructure can still be used. I've sketched that out on HN the other day:
Do you think a more ergonomic `#[no_panic]`[0] would require Rust wait for an entire effect system, or be valuable enough to add to the compiler as a one-off?
> We decided to go with Rust's
idiomatic style, i.e. keeping `rustfmt` defaults. For instance, this
means 4 spaces are used for indentation, rather than a tab. We are
happy to change that if needed -- we think what is important is
keeping the formatting automated.
Hahaha, preemptive offering compromise on tabs vs spaces warms my soul, good stuff.
I also like the strategically elevated abstraction. Doesn't even mater how many warriors are sent into this battlefield, we're not even gonna show up. Although not really novel these days with respect to formatting. Perhaps IT is growing up?
> The project is still in an early phase with the goal to compile the offical Rust test suite. There are no immediate plans for a borrow checker as this is not required to compile rust code and is the last pass in the RustC compiler.
This is essentially a reimplementation of rustc. I'm not going to say "don't boil the ocean" but it will likely be a while before this is at feature parity with the main compiler. Even with a full-time developer.
There is a project to use gcc as a backend for rustc, which might be a more tractable option to removing the llvm dependency in the short term:
This is as much good news for Linux as it is for Rust. In the long run, there is a nontrivial risk that Linux could be replaced by an OS written in a safer language. Moving to a safer language within Linux is likely to ensure Linux's long-term survival in smartphones and servers alike.
The good news is that Rust is going to need to get serious about first-tier support for all architectures supported by the Linux kernel if this is to go anywhere.
On the server side I think Linux will be replaced with something more resembling a hypervisor for WASM rather than another OS. Of course even here Linux will die at mainframe speeds if not slower. As a toolbox for IT experts it may live on forever if it doesn't calcify.
Does Rust support every architecture that the kernel supports? Seriously asking, not rhetorical.
I get that new Rust code will be limited to modules, but here's my concern:
I do work for embedded systems based on the PPC architecture. I'm not sure if Rust supports PPC, but let's just assume we're talking about an architecture that's not supported.
Suppose some company creates a PCIe Ethernet adapter and writes their driver in Rust. If Rust doesn't support PPC, then I won't be able to use that hardware even though there's no physical or technical reason why it wouldn't work. If it was written in C like everything else, then there's a good chance it would just work (assuming they didn't make any endianness assumptions).
In fact, I'd bet that the majority of the drivers written for the kernel are really written for X86 and ARM, but just so happen to work for PPC as well for free. I'd be concerned about getting left in the dust, so to speak.
What's really cool about Rust is not that it's a technical improvement on (Ada, C, Cobol, C++, Fortran, Lisp, Haskell, ...) because it isn't yet. It has some really great features, and a lot of potential. It's still young. gccrs is required. It has quite a way to go before it can rival some of the most important _languages_ we use. It's getting there.
What's really cool is the humility, flexibility, and creativity, of the community who develop Rust.
What's really really cool is Linus is holding a hoop into the kernel
Rust is absolutely a technical improvement on some of the listed languages (C, C++, maybe FORTRAN and COBOL). The borrow checker is truly novel outside of some research languages that precede Rust. The other languages you list are sufficiently different from Rust that it’s hard to make a comparison.
Of course Rust is a technical improvement over substantially older languages. To claim otherwise is basically to claim that the twin fields of programming language theory and language design have discovered and achieved nothing in the last 40 years, which is an strange thing to believe.
As explained in the thread. Rust the language itself doesn't know what the heap is. The heap is a library-level concept. You can use Rust perfectly well in heap-less/stack-only environments.
When we see more Rust implementations, are they going to inherit Rust's package manager?
I like the security ideas of Rust, but I'm very much against a compiler including a package manager that points at a particular central repository by default, with all the political problems that that entails, not to mention longevity issues.
wrt the discussion about colored unsafe for interrupt safety, would it be possible to have functions that sleep (or whatever) take a zero-sized struct called NotInterrupt or something? Then entry points to Rust code that are known to not be called from interrupts (unsafely) construct a NotInterrupt, and the rest of the code just passes it around. I think with some clever use of phantom references, you can convince the borrow checker to prevent a NotInterrupt from outliving the context it was created for, and as it's a ZST, it should be zero-cost.
So the question is the one you asked above, but also, more generally, "is it possible to statically disallow panic on OOM?" and related things.
Rust the language itself, that is, the language + the core library, doesn't know anything about allocations at all. There are none. Concept doesn't exist. So that's fine.
Rust also provides the "alloc" library, which can be layered on top of core. This gives you standard APIs for allocation. They also contain several data structures that use allocation internally. These data structures have APIs that may panic on OOM.
So, Linus saw those things, and naturally asked questions about how required they are. The answer is "not required, but it's work to get rid of them, there's a few options, and we didn't want to do that work until we got a higher-level gut check from you."
Does this RFC include all the requisite “safe” interfaces to enable writing a fully featured driver in Rust? If not, is it theoretically possible to create those safe interfaces within Linux’s API driver infrastructure? Or will some unsafe API usage always be necessary in Rust?
I remember there was an issue writing a rust-safe wayland compositor on top of wlroots because wlroot’s ownership model was simply not able to be cast in terms of interfaces that rust was able to prove were safe. [1] Is this not an issue in Linux?
I haven't done any Linux work (except for some stuff with device tree that I've mostly forgotten), but that post I made about Way Cooler may not be generalizable to all C APIs. It's also possible that I simply was not creative enough with my API design - since that blog post a few people have reached out with alternative designs that avoid some of the issues I ran into. I haven't dug into them however, since I'm no longer interested in working on Way Cooler.
It's not so much "Rust can't represent this ownership model" as "this ownership model is basically orthogonal to Rust's so you have to put much more effort in to write idiomatic Rust code compared to writing it in C". I would love for someone to come along and prove me wrong with a better wlroots wrapper.
Also, Wayland composites are much, much simpler than the Linux kernel, so that train of thought doesn't necessarily scale out.
It will be interesting if this gains traction, while C++ in the kernel never did. Many, many bugs in the Linux kernel would have been prevented with C++ (the entire class of `goto cleanup;` bugs, for example).
> Would this make Linux the first *NIX-based OS that is written in a language other than C? At least, with high usage...
It depends, but it's certainly not the first POSIX implementation in some high level language other than C. For example:
* Real-Time Executive for Multiprocessor Systems (RTEMS) is a real-time operating system (RTOS) designed for embedded systems. While it's often compiled down to as slim-as-possible it does support POSIX, and it's written in Ada. It's been used in a lot of projects, but because it's really an RTOS, RTEMS is typically embedded within dedicated systems and not something you'd normally interact with directly. https://en.wikipedia.org/wiki/RTEMS
* The BiiN system had an operating system written in Ada, and I think it implemented most of POSIX. However, the BiiN hardware never sold well, so it disappeared. I can't even find much about it on the web.
* BeOS implemented a lot of POSIX, and it was mostly C++. Haiku re-implements much of BeOS and is also written mostly in C++.
If you don't qualify it with "high usage", redox is that. There's also a semantic question; is Linux with some drivers done in Rust really an OS written in a language other than C? It's not like they intend to replace all the existing C with Rust.
Might be useful to recall that Rust's 1.0 release was in 2015. It may be a little premature to reimplement parts of Linux in such a young language... Rust may be a fad and may not catch on. I have used it a bit and I don't think it offers many significant benefits over C++.
Rust seems neat but one thing I've always liked about Linux is how few dependencies it needs to compile. The current rust compiler is not small and depends on LLVM which is not great.
[+] [-] steveklabnik|5 years ago|reply
I am pleased that these are all addressable things. We'll see!
[+] [-] flashgordon|5 years ago|reply
I actually loved (I mean really loved) reading the response as it not only was encouraging but also highly respectful and almost glowing with a trained sort of nuance! Just wow!
[+] [-] yagizdegirmenci|5 years ago|reply
This RFC is accepted and implemented. See the Josh's answer[2].
[1]: https://github.com/rust-lang/rfcs/blob/master/text/2116-allo... [2]: https://lore.kernel.org/lkml/YHdSATy9am21Tj4Z@localhost/
[+] [-] pedrocr|5 years ago|reply
https://news.ycombinator.com/item?id=26191644
[+] [-] xiphias2|5 years ago|reply
[+] [-] nynx|5 years ago|reply
It's pretty hacky, but it works on no_std.
[+] [-] yazaddaruvala|5 years ago|reply
[0] https://github.com/dtolnay/no-panic
[+] [-] dbrgn|5 years ago|reply
[+] [-] joseluisq|5 years ago|reply
[+] [-] caslon|5 years ago|reply
[+] [-] thayne|5 years ago|reply
[+] [-] easton|5 years ago|reply
[+] [-] mlindner|5 years ago|reply
[+] [-] asimpletune|5 years ago|reply
Hahaha, preemptive offering compromise on tabs vs spaces warms my soul, good stuff.
[+] [-] acje|5 years ago|reply
[+] [-] cbmuser|5 years ago|reply
> https://rust-gcc.github.io/
Having Rust support directly built into GCC means Rust code in kernel will not limit portability and no additional toolchain will be needed.
[+] [-] habitue|5 years ago|reply
This is essentially a reimplementation of rustc. I'm not going to say "don't boil the ocean" but it will likely be a while before this is at feature parity with the main compiler. Even with a full-time developer.
There is a project to use gcc as a backend for rustc, which might be a more tractable option to removing the llvm dependency in the short term:
https://github.com/antoyo/rustc_codegen_gcc
[+] [-] jasonhansel|5 years ago|reply
[+] [-] alrs|5 years ago|reply
[+] [-] nynx|5 years ago|reply
[+] [-] Thaxll|5 years ago|reply
[+] [-] acje|5 years ago|reply
[+] [-] otabdeveloper4|5 years ago|reply
I understand developer thoughts on this are skewed (job security, promotions, fun, etc.), but please. Don't.
[+] [-] joseluisq|5 years ago|reply
https://lkml.org/lkml/2021/4/14/1130
[+] [-] dochtman|5 years ago|reply
https://github.com/Rust-for-Linux/linux/issues/2
[+] [-] Unklejoe|5 years ago|reply
I get that new Rust code will be limited to modules, but here's my concern:
I do work for embedded systems based on the PPC architecture. I'm not sure if Rust supports PPC, but let's just assume we're talking about an architecture that's not supported.
Suppose some company creates a PCIe Ethernet adapter and writes their driver in Rust. If Rust doesn't support PPC, then I won't be able to use that hardware even though there's no physical or technical reason why it wouldn't work. If it was written in C like everything else, then there's a good chance it would just work (assuming they didn't make any endianness assumptions).
In fact, I'd bet that the majority of the drivers written for the kernel are really written for X86 and ARM, but just so happen to work for PPC as well for free. I'd be concerned about getting left in the dust, so to speak.
[+] [-] steveklabnik|5 years ago|reply
[+] [-] timw4mail|5 years ago|reply
[+] [-] eointierney|5 years ago|reply
What's really cool is the humility, flexibility, and creativity, of the community who develop Rust.
What's really really cool is Linus is holding a hoop into the kernel
[+] [-] dodobirdlord|5 years ago|reply
Of course Rust is a technical improvement over substantially older languages. To claim otherwise is basically to claim that the twin fields of programming language theory and language design have discovered and achieved nothing in the last 40 years, which is an strange thing to believe.
[+] [-] alfiedotwtf|5 years ago|reply
[+] [-] mlindner|5 years ago|reply
[+] [-] young_unixer|5 years ago|reply
I like the security ideas of Rust, but I'm very much against a compiler including a package manager that points at a particular central repository by default, with all the political problems that that entails, not to mention longevity issues.
[+] [-] steveklabnik|5 years ago|reply
[+] [-] ndesaulniers|5 years ago|reply
[+] [-] Gaelan|5 years ago|reply
[+] [-] myrrlyn|5 years ago|reply
[+] [-] dochtman|5 years ago|reply
https://github.com/Rust-for-Linux/linux/issues/2
[+] [-] secondcoming|5 years ago|reply
Does Rust always panic on allocation failure?
[+] [-] steveklabnik|5 years ago|reply
No. See more below.
> Can someone expand on the debate about alloc()?
So the question is the one you asked above, but also, more generally, "is it possible to statically disallow panic on OOM?" and related things.
Rust the language itself, that is, the language + the core library, doesn't know anything about allocations at all. There are none. Concept doesn't exist. So that's fine.
Rust also provides the "alloc" library, which can be layered on top of core. This gives you standard APIs for allocation. They also contain several data structures that use allocation internally. These data structures have APIs that may panic on OOM.
So, Linus saw those things, and naturally asked questions about how required they are. The answer is "not required, but it's work to get rid of them, there's a few options, and we didn't want to do that work until we got a higher-level gut check from you."
Does that all make sense?
[+] [-] CyberRabbi|5 years ago|reply
I remember there was an issue writing a rust-safe wayland compositor on top of wlroots because wlroot’s ownership model was simply not able to be cast in terms of interfaces that rust was able to prove were safe. [1] Is this not an issue in Linux?
[1] http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...
[+] [-] timidger|5 years ago|reply
It's not so much "Rust can't represent this ownership model" as "this ownership model is basically orthogonal to Rust's so you have to put much more effort in to write idiomatic Rust code compared to writing it in C". I would love for someone to come along and prove me wrong with a better wlroots wrapper.
Also, Wayland composites are much, much simpler than the Linux kernel, so that train of thought doesn't necessarily scale out.
[+] [-] steveklabnik|5 years ago|reply
"The intention is to make these as safe as possible so that modules written in Rust require the smallest amount of `unsafe` code possible."
When writing a kernel, some unsafe somewhere is always required, on some level.
[+] [-] jeffbee|5 years ago|reply
[+] [-] tomphoolery|5 years ago|reply
[+] [-] dwheeler|5 years ago|reply
It depends, but it's certainly not the first POSIX implementation in some high level language other than C. For example:
* Real-Time Executive for Multiprocessor Systems (RTEMS) is a real-time operating system (RTOS) designed for embedded systems. While it's often compiled down to as slim-as-possible it does support POSIX, and it's written in Ada. It's been used in a lot of projects, but because it's really an RTOS, RTEMS is typically embedded within dedicated systems and not something you'd normally interact with directly. https://en.wikipedia.org/wiki/RTEMS
* The BiiN system had an operating system written in Ada, and I think it implemented most of POSIX. However, the BiiN hardware never sold well, so it disappeared. I can't even find much about it on the web.
* BeOS implemented a lot of POSIX, and it was mostly C++. Haiku re-implements much of BeOS and is also written mostly in C++.
[+] [-] yjftsjthsd-h|5 years ago|reply
[+] [-] bjourne|5 years ago|reply
(The Rust brigade is out in force I see :))
[+] [-] person_of_color|5 years ago|reply
[+] [-] swiley|5 years ago|reply