Rust in Linux will be fantastic except for compile time. Rust (and the world) needs a Manhattan Project to build a fast Rust compiler (where by "fast" I mean both efficient and scalably parallel when compiling a workspace with many crates and long dependency chains).
To put this in perspective, though: increasing the number of people paid to work on the Rust compiler by 10x would only mean hiring about 25 people. Compared to the size of the projects that are starting to depend on Rust, that's a rounding error.
Typescript allows to compile without type checking at the sacrifice of correctness. If you would have a slow computer or huge code-base, you could consider using the type checker only for tests, pre-checkin check, or CI. (Not that Typescript is slow - but as an conceptual example)
Would something similar be possible for Rust, so you still have the ability for correctness for CI and release builds, but allow for fast compilation when necessary or desired?
I know a lot of people will disagree with me, and I know that the rust compiler has room for improvement, but compile time isn't really that bad for rust when you consider what it actually does for you.
Assuming no unsafe blocks, rust's type system eliminates entire classes of memory safety errors. It fundamentally eliminates data races. It eliminates large swaths of logical errors, due to its use of algebraic data types, and strong type enforcement. No null pointers, explicit error handling, and no undefined behavior.
It boggles my mind that people will balk at compile times for rust, but then not even bat an eye at their C++ testkit that runs for 8+ hours, primarily checking for errors that rust would never let you make in the first place.
> Rust in Linux will be fantastic except for compile time. Rust (and the world) needs a Manhattan Project to build a fast Rust compiler (where by "fast" I mean both efficient and scalably parallel when compiling a workspace with many crates and long dependency chains).
A basic technique to parallelize sections is to split a project into modules. Is this not an option for the linux kernel?
https://github.com/StanfordSNR/gg - should be almost the same as the GCC/LLVM thunk extractor. You have to pay for the borrow checker, but LLVM IR optimization passes should be the same complexity.
> increasing the number of people paid to work on the Rust compiler by 10x would only mean hiring about 25 people.
Citation needed ?
I know at least 20 people being paid to work on the Rust compiler, which crank's your 10x number from 25 to 200. And this is only the people I can come up with from the top of my head.
Yes, we should have a national politburo assign funds to Rust development. Although most of private industry (proles) disagrees, us in the Administration believe that Rust is superior. The proles--ahem I mean programmers with jobs--keep causing problems by using Unsafe technologies and being too dumb to use them. Rust should be funded by The People. It is a Public Good after all because using anything else would be an act of defiance against the will of The People.
> increasing the number of people paid to work on the Rust compiler by 10x would only mean hiring about 25 people. Compared to the size of the projects that are starting to depend on Rust, that's a rounding error.
And are you going to pay for the "rounding error" or just expecting someone to pay for millions a year for your idea?
> increasing the number of people paid to work on the Rust compiler by 10x would only mean hiring about 25 people
I don't think there are 25 people qualified to do that work looking for jobs. It's not something you can just throw money at, you need really qualified people to do that kind of work. Those people are in very high demand.
> a Manhattan Project to build a fast Rust compiler
Or work on getting what Rust gives you in a different language that isn't Rust (maybe entirely new, maybe not[1]).
One underdiscussed thing about Rust is that it's so clearly a byproduct of the C++ world. And the most disappointing thing about Rust is that it probably won't ever be seen as a prototype that should be thrown away.
These threads always devolve into "rust is too slow" written by developers (or enthusiasts) that have never written no_std code in production. I've written and shipped firmware for embedded devices written in rust, yes, still using cargo and external crates, and had zero issues with compile time because the nature of the dependencies in the deps tree is different and very carefully curated.
Anyway, I really just wanted to point out that from the mailing list we have Linus and Greg endorsing this experiment/effort from the Linux side and a commitment from Josh on behalf of the rust team to grow the language itself with the needs of the kernel in mind. That's quite impressive and more than I could have hoped for.
I've actually played with writing kernel code in rust - for Windows/NT, however - and it's quite weird to be able to use such high-level type constructs in code where you typically manually chases pointers and wouldn't be surprised to see statically allocated global variables used to monitor reference counts.
The title is not very accurate, this is a thread about a discussion on this topic which will happen at the upcoming Linux Plumbers Conference in late August.
I see what you mean. I just posted it here with the same title that was used on /r/Linux, and that I found accurate (for the same reasons chrismorgan exposed in a sibling comment) but now I agree with you that it could cause some confusion.
Maybe a moderator could rename the post to “discussion about Linux kernel in-tree support” or something like that?
The title is perfectly accurate, it’s an email thread about Linux kernel in-tree Rust support. Sure, you could misconstrue such a title to be implying that the Linux kernel supports Rust in-tree already it if you wanted to, but half the titles on a site like this could be similarly misconstrued.
I don't see them discussing what I view as the biggest question of such conversion: is the converted code safer than C, or is it a direct translation with all the issues that we were trying to fix by using Rust? (This came up, IIRC, with automatic C to Go; it worked, but was only useful as a first step because it gave you unsafe unidiomatic Go code)
Perhaps the possibility of rust improving kernel security/robustness makes the idea of rust integration seem like it carries its own weight, where C++ has more downsides (perceived or real) and fewer upsides.
Rust's history/origins - loosely, being designed to allow replacing Mozilla's C/C++ with safer Rust that performs well - feel like a good fit for kernel drivers even if the core kernel bits will always be C.
Yes, very much so. Not even only in the context of Rust but the insight, to fail fast, integrate early and do work in the open, instead of some hidden work, failing after a long time, when revealed.
So this surprises me, obviously this is early discussion about a potential topic, but the general consensus seemed to be more positive than I thought.
I thought I'd remembered reading something (maybe from linus) that seemed very against having rust in the kernel, can anyone find a source for that, I searched a little and can't?
(caveat, I obviously realise that linus isn't supporting rust in the kernel, and is only saying something bounded that, if we have it, it shouldn't be completely hidden behind some config options, but it doesn't match my memory)
Just stating something obvious since I don't see it noted here: Linus is a smart guy with this idea of not wanting it to be some niche feature that nobody enables and hence nobody cares about and sees breakage from.
6 months ago, as I hopped on the Rust train, I told a friend of mine that I'm convinced that Rust will "eat the world" like Python did[0]. These moves to see Rust enter the Linux kernel only prove to me that this pace is starting to pick up.
GCC can still compile the components written in C. Only drivers for select hardware might be written in Rust in the future, optional components basically. And GCC won't be more disadvantaged than clang, as clang can't compile Rust code either. The only production compiler that can compile Rust is rustc.
Depends how you define "in the kernel". In terms of what is compiled into the kernel image, it's C plus small pieces of assembler (both inline and in separate files). This proposal (if it ever happens) would be about adding Rust to that. If you mean the tree used to build the kernel, you could say it includes shell script, Makefiles, the Kconfig descriptions, and more. If you mean all the bits you need to have a very minimally working system which boots, you'd want to include all the languages used for the necessary userspace tools like the init system and udev (although the vast majority of that is also C and shell scripts).
I'm a bit uninformed as well. Obviously it must use assembly in some places, it has makefiles for building and some scripts in perl. Here's what a cloc clone has to say.
Tangential question: what would be a career path for a typical product developer to become one of the programming gods who get invited to such discussions? (Even if it's technically open mailing list, you know what I mean). How many years of experience and how much formal CS education would it take to acsend to that level?
The problem I perceive with Rust as a language for Linux, is not that Rust is not an excellent language. It is that it evolves rather quickly and code may break when you switch versions.
While I like Rust I still picked Modern C++(17) for my next project. All modern languages are converging these days.
Adopted C++ because of its libraries at large. Will still learn Rust on the side. For the moment, boring and verified for product especially when they're updating and remaining up to date.
To bootstrap Rustc you have to compile every single version. Say goodbye to reproducible builds. Say goodbye to civilians with cheap laptops being able to compile their kernel.
But to get the most value out of Rust, one needs to use the Cargo ecosystem too (even for kernel code!) and that will be a much bigger political quagmire.
[+] [-] roca|5 years ago|reply
To put this in perspective, though: increasing the number of people paid to work on the Rust compiler by 10x would only mean hiring about 25 people. Compared to the size of the projects that are starting to depend on Rust, that's a rounding error.
[+] [-] crazypython|5 years ago|reply
Dlang compiles quickly not because the language is simple, but because the compiler authors care about compilation speed:
Lexer skips four spaces at once https://github.com/dlang/dmd/pull/11095
Optimize core logic to 7x compilation speed of language feature https://github.com/dlang/dmd/pull/11303
Cache rarely used types to improve memory locality https://github.com/dlang/dmd/pull/11363
[+] [-] sebazzz|5 years ago|reply
Would something similar be possible for Rust, so you still have the ability for correctness for CI and release builds, but allow for fast compilation when necessary or desired?
[+] [-] the8472|5 years ago|reply
[+] [-] darksaints|5 years ago|reply
Assuming no unsafe blocks, rust's type system eliminates entire classes of memory safety errors. It fundamentally eliminates data races. It eliminates large swaths of logical errors, due to its use of algebraic data types, and strong type enforcement. No null pointers, explicit error handling, and no undefined behavior.
It boggles my mind that people will balk at compile times for rust, but then not even bat an eye at their C++ testkit that runs for 8+ hours, primarily checking for errors that rust would never let you make in the first place.
[+] [-] rumanator|5 years ago|reply
A basic technique to parallelize sections is to split a project into modules. Is this not an option for the linux kernel?
[+] [-] crb002|5 years ago|reply
[+] [-] fluffything|5 years ago|reply
Citation needed ?
I know at least 20 people being paid to work on the Rust compiler, which crank's your 10x number from 25 to 200. And this is only the people I can come up with from the top of my head.
[+] [-] zoul|5 years ago|reply
[+] [-] Ericson2314|5 years ago|reply
Trying to get a program to quickly do the exact same thing over and over again is a colossal waste of resource.
[+] [-] Kenji|5 years ago|reply
[deleted]
[+] [-] zelly|5 years ago|reply
[+] [-] mekster|5 years ago|reply
And are you going to pay for the "rounding error" or just expecting someone to pay for millions a year for your idea?
[+] [-] alfiedotwtf|5 years ago|reply
For the lifetime of a binary, compilation time is like 0.000001% of its existence.
I’m more than happy to wait longer compared to other languages (even zero time at all with scripting languages) while cargo does it’s thing.
[+] [-] coldpie|5 years ago|reply
I don't think there are 25 people qualified to do that work looking for jobs. It's not something you can just throw money at, you need really qualified people to do that kind of work. Those people are in very high demand.
[+] [-] cxr|5 years ago|reply
Or work on getting what Rust gives you in a different language that isn't Rust (maybe entirely new, maybe not[1]).
One underdiscussed thing about Rust is that it's so clearly a byproduct of the C++ world. And the most disappointing thing about Rust is that it probably won't ever be seen as a prototype that should be thrown away.
1. http://mbeddr.com/
[+] [-] ComputerGuru|5 years ago|reply
Anyway, I really just wanted to point out that from the mailing list we have Linus and Greg endorsing this experiment/effort from the Linux side and a commitment from Josh on behalf of the rust team to grow the language itself with the needs of the kernel in mind. That's quite impressive and more than I could have hoped for.
I've actually played with writing kernel code in rust - for Windows/NT, however - and it's quite weird to be able to use such high-level type constructs in code where you typically manually chases pointers and wouldn't be surprised to see statically allocated global variables used to monitor reference counts.
[+] [-] ksec|5 years ago|reply
Why is that? Did he ever gave out his reasons?
[+] [-] pjmlp|5 years ago|reply
[+] [-] rwmj|5 years ago|reply
[+] [-] littlestymaar|5 years ago|reply
Maybe a moderator could rename the post to “discussion about Linux kernel in-tree support” or something like that?
[+] [-] chrismorgan|5 years ago|reply
[+] [-] xvilka|5 years ago|reply
[1] https://immunant.com/blog/2020/06/kernel_modules/
[2] https://github.com/immunant/c2rust
[+] [-] yjftsjthsd-h|5 years ago|reply
[+] [-] pepijndevos|5 years ago|reply
[+] [-] xvilka|5 years ago|reply
[+] [-] for_xyz|5 years ago|reply
Initially he started with C and GTK+ and later migrated to C++ and QT Framework.
[1] https://subsurface-divelog.org/
[+] [-] kevingadd|5 years ago|reply
Rust's history/origins - loosely, being designed to allow replacing Mozilla's C/C++ with safer Rust that performs well - feel like a good fit for kernel drivers even if the core kernel bits will always be C.
[+] [-] buster|5 years ago|reply
[+] [-] mijoharas|5 years ago|reply
I thought I'd remembered reading something (maybe from linus) that seemed very against having rust in the kernel, can anyone find a source for that, I searched a little and can't?
(caveat, I obviously realise that linus isn't supporting rust in the kernel, and is only saying something bounded that, if we have it, it shouldn't be completely hidden behind some config options, but it doesn't match my memory)
[+] [-] gtirloni|5 years ago|reply
https://marc.info/?l=openbsd-misc&m=151233345723889&w=2
[+] [-] asveikau|5 years ago|reply
[+] [-] xondono|5 years ago|reply
Is there anyway to have them shown more friendly?
[+] [-] daenz|5 years ago|reply
0. https://www.techrepublic.com/article/python-is-eating-the-wo...
[+] [-] rwmj|5 years ago|reply
[+] [-] est31|5 years ago|reply
[+] [-] raverbashing|5 years ago|reply
There seems to be some discussions but not sure if it's a goal
[+] [-] Jonnax|5 years ago|reply
How many other languages apart from C are there in the kernel?
[+] [-] rwmj|5 years ago|reply
[+] [-] correct_horse|5 years ago|reply
[+] [-] BlackLotus89|5 years ago|reply
[+] [-] blondin|5 years ago|reply
[+] [-] golergka|5 years ago|reply
[+] [-] 29athrowaway|5 years ago|reply
[+] [-] megous|5 years ago|reply
If not how will that work? Will some drivers be then limited to only some architectures?
[+] [-] ausjke|5 years ago|reply
Adopted C++ because of its libraries at large. Will still learn Rust on the side. For the moment, boring and verified for product especially when they're updating and remaining up to date.
[+] [-] zelly|5 years ago|reply
[+] [-] Ericson2314|5 years ago|reply
But to get the most value out of Rust, one needs to use the Cargo ecosystem too (even for kernel code!) and that will be a much bigger political quagmire.
[+] [-] Shorel|5 years ago|reply
"Immutable variable" what an oxymoron!
That's what is known as a constant!
A variable is mutable, a constant is not. Was it that hard to understand?
[+] [-] historyremade|5 years ago|reply
[deleted]