I like Rust and I'd love to see it in the Linux kernel, but not before the GCC+Rust issues are all fixed. You shouldn't need non-GCC compilers to compile Linux and from what I can tell there isn't any GCC Rust compiler that's fully equivalent to the standard Rust compiler just yet.
They say that Rust support is optional, but when the first big driver gets written in Rust it'll become mandatory. So either the Rust integration will fail and nothing important will get written in it, or it won't be optional. I'm not sure what comfort that's supposed to bring.
The GCC story isn’t that far behind - there are two complementary efforts to get GCC support into the Rust ecosystem.
One is a Rust frontend to GCC (https://github.com/Rust-GCC/gccrs) while the other is a GCC backend to the existing Rust compiler (https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-12). It might take a while for these to bear fruit, but it’ll be awesome when they do. That should address the very valid concern that the full Linux kernel won’t compile for all supported architectures.
And it’s not really a problem that the GCC effort will take time. The headline of this article implies that the Rust integration is nearly done but it’s only the beginning. Based on the issue tracker there’s years of work left to get everything working perfectly. That’s enough time to get GCC supported well.
The initial work is just scaffolding that allows using Rust for some drivers, and projects intended to test said scaffolding. (Basically, rewrites of some drivers that are already in the kernel but that are not considered to be of the greatest of quality.)
It will take quite a while yet before something important is made in Rust, and this early work can be done in parallel with the GCC-Rust work.
Yup. And if you have to use the rustc compiler that means you cannot use the rustc compiler from your repositories. Rust changes in forwards incompatible ways so fast that rustc is literally out of date and unable to compile new Rust code in less than 3 months. It's not because Rust is inherently bad, it's just that the type of people who write in rust are bleeding edge types (for now) and have no consideration for forwards compatibility.
They just assume you'll curl | rustup.whatever and install a new version of rustc every month from a third party website like every single Rust guide suggests. That's not optimal for the linux kernel. But maybe kernel dev types won't be as bad as the typical bleeding edge rust dev.
And given that rapid rate of change in Rust, I don't see how GCC can ever keep up. Maybe in 10 years when Rust is more stable.
>You shouldn't need non-GCC compilers to compile Linux
Huh? What relationship the Linux kernel and GCC has?
They're independent projects. It might be handy/nice/convenient to not need non-GCC compilers to compile Linux, but it's not like it's some license requirement or project obligation on behalf of Linux
I don't see why Rust usage in the kernel should be blocked by GCC of all things. Of course kernel has been traditionally compiled by GCC, but there was never a ban on any additional or alternative tools. There is a number of dependencies on things like make, bison and so on.
Okay but think of it this way... maybe this is creating more demand for a GCC Rust compiler. Maybe it finally gives some people the excuse or funding to do what they need to do.
We've known for some time now that the future would be written in Rust. If you do not have a Rust compiler in addition to a C compiler on your system, now is the time to consider installing one.
EDIT: It is very bit unfortunate that my general/off-topic comment is currently the most upvoted. I was not commenting on the Linux integration specifically. I'm a _novice and hobbyist_ when it comes to Rust.
I want to provoke a little bit, but I'm genuinely curious about the following:
I feel like the Rust ecosystem is still quite immature in a lot of areas. Just a few indicators to illustrate what I mean:
- Both async/await and the question mark operator feel like rushed implementations, neither seem like the best long term solutions for Rust and are not in line with the otherwise solid foundation of the language.
- Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem.
- Some projects pride themselves to not use "unsafe" code, including linking with battle tested C code, which seems like an arbitrary restriction that sounds better than it actually is. There is even an open source maintainer that got mobbed out from his own project because he used "unsafe" in places that others didn't agree with.
- Rust is fashionable. Putting "Rust" next to a HN title immediately gets clicks and upvotes. SO surveys and similar report high interest in the language. This is not an inherently bad thing, quite the opposite. But as a secondary effect it might detract from objective, technical decision making.
I really like the language, I have _way_ more good things to say about it than bad things. But am I alone in feeling like this? Other modern language communities come with a philosophy that promotes stability and simplicity. Is the Rust community riding on the merits of Rust's unique value proposition, while forgetting some important fundamentals?
This is my humble opinion, but kernel shouldn't be a place for language diversity. Even code comments should be standardized for such critical and complex project with so many participants.
If the internal APIs of the Linux kernel were boiled down to WebAssembly, then many kernel modules and drivers could be written in any language and cheaply isolated, making it harder, maybe impossible to corrupt kernel memory. IMHO that would lead to a more modular, robust kernel with lots of options for programming it, without resorting to a full microkernel design that has costly IPC.
Pardon my ignorance, but given the complexity of Rust, the incoherence of the async story etc, wouldn't something like Zig be a more reasonable choice for Linux, with its ability to be introduced gradually etc?
As other commenters have poked at; I'd hope that if Rust is going into the kernel (even if just for drivers), that means it's hopefully hopefully started to "calm down" as a language.
At least in regards to the features that affect kernel-level development. Stabilizing that doesn't preclude active development in things like async or in the standard library (both of which I'd expect not to see much or any use in the kernel.) But I'd hope for decent work towards backwards and forwards compatibility in the set of language features used there.
I think this is a bad idea or at least far too soon.
In my opinion the Rust language and eco system is not yet at
the stability of C.
I feel certain that mixing two different languages inside the kernel
will give all new and challenging errors to debug.
Also it is the fallacy of sunken cost.
So much work has gone into the Linux kernel, but efforts should be made
to replace it.
What I would like to see is a project to create a new and modern kernel,
taking a lot of what has been learned by the "prototype" Linux kernel and
create something new and better.
It would also be free to take full advantage of the language improvements
between Rust and C.
Sure it would take a lot of time, but I think it is time well invested, instead
of slowing trying to port the current Linux kernel to Rust.
I really have mixed feelings about that, but I am really curious to see what's happening.
Some people also experimented with some kernel modules written in Rust on FreeBSD.
If rust + linux is a success story, maybe FreeBSD could learn from it and adopt some ideas.
'jcranmer gave a good summary, but to add one or two more points:
* It's very difficult to predict allocation patterns in C++ (even modern variants) from just the source code. An innocent looking object allocated on the stack might have a nontrivial constructor with all kinds of side effects. Rust, while being slightly less explicit than C, is much more explicit than C++.
* Modern C++ doesn't actually play that nicely with C. C++'s aliasing rules and casting rules keep getting more and more strict, whereas kernel programming lends itself to a lot of "bag-of-bytes-to-struct"-style programming. It would be very unfortunate if adding a C++ compiler to the kernel's build broke pre-existing C code by detecting UB in the context of C++ and decided to simply erase it.
Rust's design has given more thought for how to work in the kind of programming environment that the Linux kernel sits in than C++ (even C++11) has.
Specifically (and this is no longer quite eli5), Rust's freestanding mode--working without a standard library--is somewhat fuller and more fleshed out than the C++ freestanding mode.
Now, the sibling comment that points out that C++ gained a bad reputation pre-C++11 is probably a bigger reason for it not being seriously considered whereas Rust is, but there are some technical reasons where Rust does better than C++.
C++ burnt through a lot of good will in the C++98 era where it was admittedly a hot mess (and all the compilers where buggy dumpster fires). Now on one hand we have people who publicly and loudly swore off touching C++ ever again based on this experience (and even more people parroting the “C++ is a mess” statement without any experience) and on the other the excitement of Rust with all the hype making people invest a large amount of effort into learning it.
My limited understanding is that rust provides significant advantages in terms of memory safety[1], that should reduce the chance of errors and bugs, whilst c++11 does not provide these same advantages.
I really like rust, but I really don't like how much adoption it's getting. Rust is better than basically everything else out there, but it still really feels like a stepping stone language during a time of rapid language development. Even single threaded synchronous rust has its issues and it really feels like one or two more steps will get us to a significantly better place and getting rust adopted everywhere will just come and bite us in the end.
Also, GCC should fix their stupid libjitgcc so new languages can use it reasonably instead of making everyone use llvm and then complain that there is no gcc implementation
So you know rust is the best fit, but you don't like it because of... vague reasons? Rust is the first compelling systems language since C++. This isn't an area with much attention paid to it. What is this a stepping stone towards? Zig is the only other thing that seems to get brought up, but it's not bringing any new ideas to the table. Certainly nothing close to what Rust is doing with the lifecycle checker.
But why should Linux, or anyone really, let future promises block meaningful improvements today? If something comes along that's better than Rust for this, then another adoption/migration process can happen.
I get your point, and I'm sympathetic because I had similar thoughts.
But building a successful language and ecosystem takes a combination of visionary initiators, dedicated contributors, money, a significant value add, luck , and lots of time.
Rust has warts that could be done better by a newer language. There are some interesting experiments, but I don't know of any language that would fit the bill right now.
And if that language emerges it will need many years and probably a corporate backer to reach the level of maturity required for critical workloads like the kernel.
The world shouldn't be limited to C for another 10 years.
It is correct to suspect that Rust will turn out to be a transitional language. If Rust fizzled (still very possible!) it would be embarrassing, and maybe troublesome.
I know what you mean - there is potential for something even better. That said, having something that actually is better than C/C++, and having it become widely known accepted enough that I don't really have to justify using it at work is really good.
And Rust will smooth the path for other language in the systems space. Rust had to work extra had because there has only be one dominant (pair of) languages for so long. Now that people have got used to choosing, hopefully it'll be easier next time for Rust++ or whatever.
Does anyone have context on how Rust will make its way into the kernel? I'd imagine the initial motions will be pointed towards allowing Rust code to build alongside the existing C codebase without friction. Is the intent to incrementally introduce new modules and subsystems in Rust after that? Is there an end goal to rewrite everything in Rust?
Lua would be good. Device drivers need not be all about high performance especially for initial development. Lua would be fast enough for plenty of purposes.
NetBSD has Lua support.[1] Unfortunately there doesn't seem to be a lot of published material on it. One interesting application I found was secmodel_sandbox[2] which used it to implement something similar to AppArmor.
Why should we constrain ourselves to not use the word 'safe' in the context of one of the most privileged portions of code running on a computer?
Linus has made it pretty clear that it's why he's allowing it; it provides something above and beyond other system languages wrt to writing correct code while still working with the kernel's structure and requirements (with a little elbow grease).
Rust actually does a (marginally) better job of being a low-level, almost portable assembler kind of language than C does. This isn't even really about things like undefined behavior (of which Rust still has quite a profusion), but in things like being able to actually pun types.
Additionally, Rust is a newer language that has incorporated some of the past 50 years of programming language design lessons that C has not incorporated (and likely never will).
Because 3/4ths of the security problems in C code are memory errors which rust removes, while still providing the low level code necessary to write a kernel.
[+] [-] jeroenhd|3 years ago|reply
They say that Rust support is optional, but when the first big driver gets written in Rust it'll become mandatory. So either the Rust integration will fail and nothing important will get written in it, or it won't be optional. I'm not sure what comfort that's supposed to bring.
[+] [-] nindalf|3 years ago|reply
One is a Rust frontend to GCC (https://github.com/Rust-GCC/gccrs) while the other is a GCC backend to the existing Rust compiler (https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-12). It might take a while for these to bear fruit, but it’ll be awesome when they do. That should address the very valid concern that the full Linux kernel won’t compile for all supported architectures.
And it’s not really a problem that the GCC effort will take time. The headline of this article implies that the Rust integration is nearly done but it’s only the beginning. Based on the issue tracker there’s years of work left to get everything working perfectly. That’s enough time to get GCC supported well.
[+] [-] Tuna-Fish|3 years ago|reply
It will take quite a while yet before something important is made in Rust, and this early work can be done in parallel with the GCC-Rust work.
[+] [-] superkuh|3 years ago|reply
They just assume you'll curl | rustup.whatever and install a new version of rustc every month from a third party website like every single Rust guide suggests. That's not optimal for the linux kernel. But maybe kernel dev types won't be as bad as the typical bleeding edge rust dev.
And given that rapid rate of change in Rust, I don't see how GCC can ever keep up. Maybe in 10 years when Rust is more stable.
[+] [-] coldtea|3 years ago|reply
Huh? What relationship the Linux kernel and GCC has?
They're independent projects. It might be handy/nice/convenient to not need non-GCC compilers to compile Linux, but it's not like it's some license requirement or project obligation on behalf of Linux
[+] [-] eterevsky|3 years ago|reply
[+] [-] selckin|3 years ago|reply
[+] [-] humanwhosits|3 years ago|reply
[+] [-] sophacles|3 years ago|reply
Why?
[+] [-] mkoubaa|3 years ago|reply
[+] [-] guerrilla|3 years ago|reply
[+] [-] rjsw|3 years ago|reply
[+] [-] bitwize|3 years ago|reply
[+] [-] dgb23|3 years ago|reply
For example this comment https://news.ycombinator.com/item?id=31849071 is much more interesting and on topic.
---
I want to provoke a little bit, but I'm genuinely curious about the following:
I feel like the Rust ecosystem is still quite immature in a lot of areas. Just a few indicators to illustrate what I mean:
- Both async/await and the question mark operator feel like rushed implementations, neither seem like the best long term solutions for Rust and are not in line with the otherwise solid foundation of the language.
- Open source code examples sometimes use an array of external dependencies that are unrelated to a given project and feel arbitrary. This reminds me of the JS ecosystem.
- Some projects pride themselves to not use "unsafe" code, including linking with battle tested C code, which seems like an arbitrary restriction that sounds better than it actually is. There is even an open source maintainer that got mobbed out from his own project because he used "unsafe" in places that others didn't agree with.
- Rust is fashionable. Putting "Rust" next to a HN title immediately gets clicks and upvotes. SO surveys and similar report high interest in the language. This is not an inherently bad thing, quite the opposite. But as a secondary effect it might detract from objective, technical decision making.
I really like the language, I have _way_ more good things to say about it than bad things. But am I alone in feeling like this? Other modern language communities come with a philosophy that promotes stability and simplicity. Is the Rust community riding on the merits of Rust's unique value proposition, while forgetting some important fundamentals?
[+] [-] IYasha|3 years ago|reply
[+] [-] titzer|3 years ago|reply
[+] [-] samuell|3 years ago|reply
[+] [-] cmrdporcupine|3 years ago|reply
At least in regards to the features that affect kernel-level development. Stabilizing that doesn't preclude active development in things like async or in the standard library (both of which I'd expect not to see much or any use in the kernel.) But I'd hope for decent work towards backwards and forwards compatibility in the set of language features used there.
[+] [-] PointyFluff|3 years ago|reply
[+] [-] ThinkBeat|3 years ago|reply
In my opinion the Rust language and eco system is not yet at the stability of C.
I feel certain that mixing two different languages inside the kernel will give all new and challenging errors to debug.
Also it is the fallacy of sunken cost.
So much work has gone into the Linux kernel, but efforts should be made to replace it.
What I would like to see is a project to create a new and modern kernel, taking a lot of what has been learned by the "prototype" Linux kernel and create something new and better.
It would also be free to take full advantage of the language improvements between Rust and C.
Sure it would take a lot of time, but I think it is time well invested, instead of slowing trying to port the current Linux kernel to Rust.
[+] [-] enriquto|3 years ago|reply
Also, having rust in a serious project like linux, (and omitting all the cargo madness), would be a great thing for the language.
[+] [-] fxttr|3 years ago|reply
[+] [-] DesiLurker|3 years ago|reply
[+] [-] woodruffw|3 years ago|reply
* It's very difficult to predict allocation patterns in C++ (even modern variants) from just the source code. An innocent looking object allocated on the stack might have a nontrivial constructor with all kinds of side effects. Rust, while being slightly less explicit than C, is much more explicit than C++.
* Modern C++ doesn't actually play that nicely with C. C++'s aliasing rules and casting rules keep getting more and more strict, whereas kernel programming lends itself to a lot of "bag-of-bytes-to-struct"-style programming. It would be very unfortunate if adding a C++ compiler to the kernel's build broke pre-existing C code by detecting UB in the context of C++ and decided to simply erase it.
[+] [-] jcranmer|3 years ago|reply
Specifically (and this is no longer quite eli5), Rust's freestanding mode--working without a standard library--is somewhat fuller and more fleshed out than the C++ freestanding mode.
Now, the sibling comment that points out that C++ gained a bad reputation pre-C++11 is probably a bigger reason for it not being seriously considered whereas Rust is, but there are some technical reasons where Rust does better than C++.
[+] [-] boris|3 years ago|reply
[+] [-] Arkanum|3 years ago|reply
[1] Comparison of memory safety of c vs Zig vs Rust (from elsewhere in the comments): https://www.scattered-thoughts.net/writing/how-safe-is-zig/
[+] [-] seabrookmx|3 years ago|reply
[+] [-] adwn|3 years ago|reply
[1] https://news.ycombinator.com/item?id=31832081
[+] [-] manx|3 years ago|reply
[+] [-] narimoney|3 years ago|reply
[+] [-] 3836293648|3 years ago|reply
Also, GCC should fix their stupid libjitgcc so new languages can use it reasonably instead of making everyone use llvm and then complain that there is no gcc implementation
[+] [-] kllrnohj|3 years ago|reply
But why should Linux, or anyone really, let future promises block meaningful improvements today? If something comes along that's better than Rust for this, then another adoption/migration process can happen.
[+] [-] the_duke|3 years ago|reply
But building a successful language and ecosystem takes a combination of visionary initiators, dedicated contributors, money, a significant value add, luck , and lots of time.
Rust has warts that could be done better by a newer language. There are some interesting experiments, but I don't know of any language that would fit the bill right now.
And if that language emerges it will need many years and probably a corporate backer to reach the level of maturity required for critical workloads like the kernel.
The world shouldn't be limited to C for another 10 years.
[+] [-] ncmncm|3 years ago|reply
[+] [-] rkangel|3 years ago|reply
And Rust will smooth the path for other language in the systems space. Rust had to work extra had because there has only be one dominant (pair of) languages for so long. Now that people have got used to choosing, hopefully it'll be easier next time for Rust++ or whatever.
[+] [-] vkazanov|3 years ago|reply
[+] [-] tmountain|3 years ago|reply
[+] [-] adamius|3 years ago|reply
[+] [-] nequo|3 years ago|reply
[1] https://www.netbsd.org/~lneto/bsdconbr15.pdf
[2] https://github.com/smherwig/netbsd-sandbox
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] tamrix|3 years ago|reply
I'm going to call the new c only Linux cinux
[+] [-] sdfhdhjdw3|3 years ago|reply
[+] [-] monocasa|3 years ago|reply
Linus has made it pretty clear that it's why he's allowing it; it provides something above and beyond other system languages wrt to writing correct code while still working with the kernel's structure and requirements (with a little elbow grease).
[+] [-] jcranmer|3 years ago|reply
Additionally, Rust is a newer language that has incorporated some of the past 50 years of programming language design lessons that C has not incorporated (and likely never will).
[+] [-] adgjlsfhk1|3 years ago|reply
[+] [-] varajelle|3 years ago|reply
[+] [-] josephcsible|3 years ago|reply
[+] [-] mllllv|3 years ago|reply
[deleted]
[+] [-] b20000|3 years ago|reply