'Will 2020 Be The Year Of Rust In The Linux Kernel?' (hackaday.com) 95
An intriguing exchange happened on the Linux Kernel Mailing List after a post by Nick Desaulniers, a Google software engineer working on compiling the Linux Kernel with Clang (and LLVM). Hackaday reports:
Nick simply tested the waters for a possible future of Rust within the Linux kernel code base, which is something he's planning to bring up for discussion in this year's Linux Plumbers Conference — the annual kernel developer gathering. [Desaulniers thinks that discussion will include "a larger question of 'should we do this?' or 'how might we place limits on where this can be used?'"]
The interesting part is Linus Torvalds's response on the LKML thread, which leaves everyone hoping for a hearty signature Rust rant akin to his C++ one disappointed. Instead, his main concern is that a soft and optional introduction of the support in the build system would leave possible bugs hidden, and therefore should be automatically enabled if a Rust compiler is present — essentially implying that he seems otherwise on board.
Linus also touched on Rust earlier this month in his keynote interview with Dirk Hohndel, the chief open source officer at VMware, during the special virtual edition of the Linux Foundation's annual Open Source Summit and Embedded Linux Conference North America: Dirk Hohndel: Every new project is done in Go or Rust or another new language I've never heard of. Is there a risk that we are becoming the COBOL programmers of the 2030s?
Linus Torvalds: Well, I don't actually think it's true that nobody writes in C any more. I think C is still one of the top 10 languages easily, if you look at any of the statistics.
That said — I mean, people are actively looking at, especially doing drivers and things that are not very central to the kernel itself, and having interfaces to do those, for example, in Rust. People have been looking at that for years now. I'm convinced it's going to happen one day.
I mean, it might not be Rust, but it is going to happen that we will have different models for writing these kinds of things. And C won't be the only one. I mean right now, it's C or assembly, and most people would rather not touch the assembly parts. [Dirk laughs] But it is something that people are looking at. I'm probably the wrong person. Greg has been more involved, since he's the driver maintainer in general. But things are afoot, and these things take a long, long time. I mean, the kind of infrastructure you need to start integrating other languages into a kernel, and making people trust these other languages — that's a big step.
The interesting part is Linus Torvalds's response on the LKML thread, which leaves everyone hoping for a hearty signature Rust rant akin to his C++ one disappointed. Instead, his main concern is that a soft and optional introduction of the support in the build system would leave possible bugs hidden, and therefore should be automatically enabled if a Rust compiler is present — essentially implying that he seems otherwise on board.
Linus also touched on Rust earlier this month in his keynote interview with Dirk Hohndel, the chief open source officer at VMware, during the special virtual edition of the Linux Foundation's annual Open Source Summit and Embedded Linux Conference North America: Dirk Hohndel: Every new project is done in Go or Rust or another new language I've never heard of. Is there a risk that we are becoming the COBOL programmers of the 2030s?
Linus Torvalds: Well, I don't actually think it's true that nobody writes in C any more. I think C is still one of the top 10 languages easily, if you look at any of the statistics.
That said — I mean, people are actively looking at, especially doing drivers and things that are not very central to the kernel itself, and having interfaces to do those, for example, in Rust. People have been looking at that for years now. I'm convinced it's going to happen one day.
I mean, it might not be Rust, but it is going to happen that we will have different models for writing these kinds of things. And C won't be the only one. I mean right now, it's C or assembly, and most people would rather not touch the assembly parts. [Dirk laughs] But it is something that people are looking at. I'm probably the wrong person. Greg has been more involved, since he's the driver maintainer in general. But things are afoot, and these things take a long, long time. I mean, the kind of infrastructure you need to start integrating other languages into a kernel, and making people trust these other languages — that's a big step.
No. (Score:2)
No.
Re: (Score:2)
This.
2020 may be the year when someone seriously forks a kernel with some Rust in it. 2020 is not the year when Rust is in the mainline repo.
It won't be mature or performant enough for at least another 5 years.
I wouldn't think so (Score:5, Funny)
They'll probably keep updating it rather than let it rust.
Re: (Score:1)
It's not about Rust, but it's about the kernel (Score:4)
It doesn't matter what language is being used, what matters is what the software does.
If they can write clean code in Rust, create working drivers and entire subsystems in Rust, all without losing out in performance and maintainability then they should be allowed.
I'm not holding my breath however. This is still just a lot of talk about Rust, and not about kernel code.
Re: (Score:2)
It doesn't matter what language is being used, what matters is what the software does.
If they can write clean code in Rust, create working drivers and entire subsystems in Rust, all without losing out in performance and maintainability then they should be allowed.
I'm not holding my breath however. This is still just a lot of talk about Rust, and not about kernel code.
To quote the Spartan ephors: IF
Re: (Score:2)
The problem is that as soon as you start permitting X in the kernel, then you must allow X+1
If Rust is stable, like not C++ (updated every 3 years does not make it stable, if anything it makes it unstable due to extensive feature creep) then it has some possibility of being acceptable and can be programmed in as an alternative to C or C++.
However in practice the reason why C is the one and only true language to develop things in, is that the manual memory management is it's strength, but developers frequent
Re:It's not about Rust, but it's about the kernel (Score:4, Informative)
the reason why C is the one and only true language to develop things in, is that the manual memory management is it's strength
Rust also has manual memory management.
The difference is that Rust uses the equivalent of smart-pointers by default. So dangling pointers are avoided.
If you really, really want to write a memory leak, you can do it by calling "std::mem::forget", but that makes it obvious.
Disclaimer: I don't use Rust, but I have no religious objection to it. Rust has some nice features.
Re: (Score:2)
The problem is that as soon as you start permitting X in the kernel, then you must allow X+1
No.
The problem is that those who want to contribute to the kernel in another language will have to come up with something that's better than what we already have. If it then sucks then it doesn't matter what language it is in.
If it's indeed better, then there is something to learn from. And you can then rewrite it in C if this important to you. Just send patches.
You don't like this? Fork and make your own kernel. Don't start saying you have a problem with how open source works.
Re: It's not about Rust, but it's about the kernel (Score:2)
C++ is a better C, yet it is not allowed.
It's more about coding guidelines and control.
Re: (Score:2)
C++ is a special case, but you're right if you meant to say it should be allowed, too.
The problem with C++ is however that it is not simply a different language, but it is a superset of C. Anyone who can write in C++ can write C. So nobody is really kept from contributing. C++ can then get very complex and hard to read once you start using all it's features. Plus you end up with quite a few people who rewrite existing C code in C++ for no other reason than to change the code base, and who thereby waste a lo
Re: (Score:2)
Anyone who can program in Rust can program in C.
They just have to apply their ability to learn a programming language to learn a different one.
Your attitude assumes that Rust programmers know nothing else, not javascript or python or any of the other "cool" languages that abound today.
Re: (Score:2)
Your attitude assumes ...
No, my attitude doesn't assume this. We're not talking about the people. Rust is a different language and one which has its benefits that sets it apart from C.
Re: (Score:2)
Anyone who can write in C++ can write C
As someone had a co-worker once upon a time in the early aughts, who wondered why you couldn't pass by reference in C, I call bullshit.
Re: (Score:2)
Or your mate just wasn't smart enough to program in either C or C++.
Re: (Score:2)
C++ can be used as a better C (essentially, C with namespaces, constexpr, a little ad hoc overloading, and light use of templates instead of preprocessor hackery). This is what most operating system kernels written in C++ do.
What C++ can't do is statically prevent you from using the stuff-you-don't-want-for-Linux at compile time (apart from RTTI and EH; most compilers give you a way to turn that off). In a highly distributed development model, that alone is a good reason not to use C++.
Re: (Score:3)
The worst language to develop high performance software in, are scripting languages (eg python), as it comes with large CPU expenses.
Depends on what you're trying to do. Pandas can very quickly manipulate huge datasets for example. I do the same in powershell, though I don't rely on cmdlets, instead relying on .net calls where performance is needed. Though personally I tend to use a mix of scripting languages and compiled languages in a given project -- prototyping that way is so much easier.
Re: (Score:2)
They're not exactly threatened, unless being threatened by themselves counts. They're kind of this odd animal that has a carnivorous body that chooses to meet its nutritional needs by eating plants that it can't adequately get nourishment from, and many of the males can't even figure out where exactly they're supposed to put their dicks in order to breed.
Re: (Score:2)
You can step down into arbitrary levels of unsafe system programming in Rust. You can't step up to having bounds checking, by design lack of dangling pointers and sane built in constructs for multithreaded data sharing in C.
That Rust isn't ready is because the IT industry didn't start working on something like it three decades ago, when it was already blatantly obvious it was needed. But better late than never.
Re: It's not about Rust, but it's about the kernel (Score:2)
Multithreading is an OS concept, not a language concept. It's only shoehorned into various languages to stop 2nd rate programmers getting burnt when they try to use it. But why stop there? Why not build multiprocess handling direct into the language? Or file handling, or network control? Its BS. A language should provide control logic and basic maths paradigms, end of, not OS concepts. Everything else should be handled by libraries. And in the case of C++ threading you end up with a lousy lowest common den
Re: (Score:2)
It's somewhere between hard and impossible to have compile time guarantees on thread safety of data sharing if it's not build into the language. Rust also has constructs for safe multithreaded access to files indeed, as it should be.
All programmers act 2nd rate sometimes, only the frequency varies. The only sane thing to do is to have the compiler and runtime checks protect them against themselves according to rational risk/benefit analysis... you and every C defender out there have not been rational for de
Re: It's not about Rust, but it's about the kerne (Score:2)
Seems you have no idea what 3 level locking is and how crucial it is for certain constructs. So how would you have compile time guarantees of shared memory/pipe/socket/fido safety with multiprocess then given no language does (or could do) that? Perhaps in your world we just shouldn't use fork() ever again because theres nothing to protect you from yourself? Or maybe you're just a tit.
Re: (Score:2)
You can implement any locking mechanism you damn well please in Rust too, if it needs to be unsafe do it unsafe.
You can't get compile time guarantees on ownership for something simple like single access in C, there can be pointers to it all over the place for all the compiler knows. It's unsafe by default, rather than by strictly limited exception. Code analysis can't fix this, false positives and negatives will abound.
MISRA C tools/etc can't give guarantees on thread isolation, dangling pointers and buffer
Re: It's not about Rust, but it's about the kernel (Score:2)
Rust is just a language developed by bad C++ programmers who wrongly thought they needed to enforce their bad practices to whole projects or systems.
Have you ever looked at Mozilla C++ code? No wonder they came up with such a terrible language. They completely misunderstood C++.
Re: (Score:2)
That Rust isn't ready is because the IT industry didn't start working on something like it three decades ago, when it was already blatantly obvious it was needed.
I can't speak for the IT industry, which is arbitrary and insane, but programming language researchers have indeed been working on the problem for decades. Rust is the beneficiary of research systems such as Alef and Cyclone.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
C++ was rejected, rightly, because it's an unholy mess of a language, with it being so overbuilt and overcomplicated it's hard to find C++ programmers who can read each other's code,
This is just flat out not true: a huge amount of native code in industry is written in C++. Hell the compilers that Linux relies on are now written in C++.
The reason C++ wasn't used in the kernel is that Linus had some very angry, very inaccurate ideas about it and got too big for anyone the be able to tell him he's being an idi
Re: It's not about Rust, but it's about the kernel (Score:2)
Generally speaking, the average C++ developer is worse than the average C developer, because C has established itself in a very demanding niche, while C++ is used for everything.
Because of that there is more bad C++ code out there than bad C, which badly reflects on the quality of the language itself.
Re: (Score:2)
Re: It's not about Rust, but it's about the kernel (Score:2)
Script languages are tricky beasts. For a kernel it's important that any language used has a deterministic behavior. If there's an upgrade to the language engine that improves security in userspace it could result in slowed down hardware drivers or a kernel that won't run.
I have toyed with the idea of using Fortran for some kernel parts, but it's also then depending on runtime library support, at least partially.
Overall the kernel environment has different demands compared to userspace so therefore only cer
Re: It's not about Rust, but it's about the kerne (Score:2)
Determinism on a superscalar processor with sophisticated cache hierarchies?
You're not even guaranteed to have the same codegen every time you touch the source code somewhere else in C, even with the same version of tools.
Re: (Score:2)
C is still one of the languages with the most deterministic behavior when compiled and when you build for a kernel then you don't have to use the memory allocation randomization, it can even cause a lot of trouble. For userspace application then the memory allocation randomization is useful to lower the risk of malicious injections.
Re: (Score:2)
but developers frequently ignore warnings during the compile stage, and release code that "works" but is really broken.
Which is one of the strengths in Rust. You don't get a binary till you prove to the compiler that you code is going to check the memory before you de-reference it or you mark it unsafe. If you honestly think you know better, then you get to tag the code unsafe (and put your name to it) and the compiler trusts you, otherwise, you don't get to "just ignore the warnings".
Re: (Score:1)
^^^ This. From the summary:
Dirk Hohndel: Every new project is done in Go or Rust or another new language I've never heard of. Is there a risk that we are becoming the COBOL programmers of the 2030s?
Linus Torvalds: Well, I don't actually think it's true that nobody writes in C any more. I think C is still one of the top 10 languages easily, if you look at any of the statistics.
What happened to "use the best tool for the job"? Whether a language is popular or not, by itself shouldn't matter (it could if eg. using an exotic language makes things harder to maintain). If for some parts Rust does a better job than C or assembly, why not use it? If it doesn't, who cares whether it's popular, fashionable, or has feature X or Y?
Yes for "does a better job" one could read: "programmers writing in it, do a better job". No doubt t
Re: (Score:2)
It doesn't matter what language is being used, what matters is what the software does.
If they can write clean code in Rust, create working drivers and entire subsystems in Rust, all without losing out in performance and maintainability then they should be allowed.
I'm not holding my breath however. This is still just a lot of talk about Rust, and not about kernel code.
I could see Rust being used for prototyping the new software, and then having a translator from Rust source to C. Why that step? It is best that a huge application be maintained with one proven language. The C translation would include the "faux-pas" (don't dos) in the code and style imposed by Rust .
Portability (Score:5, Insightful)
Rust doesn't have anywhere near the portability that C does yet. Mainstream AMD64 platforms will be fine, but embedded and mobile systems need considerable work in Rust to get it on par with where C already is on these platforms.
Re: (Score:2)
Rust runs on ARM. You can compile and run Rust programs on a Raspberry Pi.
There is an active project to port Rust to the AVR microcontroller. So you will soon be able to run Rust on an Arduino.
Re: (Score:2)
Re: and? (Score:2)
To be fair, most of these are either long dead, legacy, or irrelevant.
Re: (Score:2)
Rust runs on ARM.
It is NOT gauranteed to run on ARM. [rust-lang.org]
The ONLY Tier 1 supported archs are x86/i686. This is not a theoretical problem. Rust does NOT work reliably on ARM.
Re: (Score:2)
Re: (Score:2)
tier 2 tables - the likes of IoT and embedded controllers where Linux is installed.
Re: (Score:2)
"The ONLY Tier 1 supported archs are x86/i686."
Those are the ones that they routinely run CI tests on. Given how long the tests take to run, doing that for all platforms would be expensive and time consuming.
The tier 2 ones are supported in the sense that the code can be built on them, and is *expected* to run. If it doesn't that would be considered a bug. If you were targetting that platform, there is nothing to stop you building and running the tests yourself. Or, you could just stick with an older versio
Re: (Score:2)
Rust can run on an STM32 using an M4F core. If this is possible, there is no reason why writing for anything that supports embedded Linux would be an issue. See embedded rust [rust-lang.org].
It would be interesting if instead of a rust interface, the was instead a focus on facilitating an interface to LLVM object code. That way you could use rust, go, or a future language (almost everything new is based on LLVM). I do not know how realistic this would be but a more generic, language neutral interface solution might
Re: (Score:2)
Why not just support the C ABI in this case?
I think the ideas is have nice interfaces which look Rust like implemented over the top of the C ones.
Re: (Score:2)
Re: (Score:2)
And besides, Rust is just a front end compiler for LLVM so any back end supported by LLVM can be supported by Rust. The Linux kernel is built with LLVM for some targets like Android (using the Clang front end) so honestly I don't see this argument having much merit at all.
Hello no. (Score:2)
Stability (Score:4, Interesting)
This matters in the Linux kernel because you don't want to rewrite a driver for a piece of hardware from 5 years ago. You might not even have the hardware still lying around, even though the hardware is still used by a lot of people.
Re: (Score:1)
I think you are wrong here. Rust doesn't have the same *evidence* of stability, but then that would be impossible for any language younger than 1980. It does have a *committent* to stability, though, which you are free to believe or not as you choose.
Re: (Score:3)
C hasn't broken anything for 20 years (Score:4, Insightful)
The Rust project talks about backward compatibility, which is great. They don't want mess of three mutually incompatible versions in two years that was Python 2.6, 2.7, and 3.0.
So the Rust team ralks about it. What do they DO about it? Rust policy is that breaking changes will be done in new "editions", which will come out "every two to three years". So if you write Rust cose today, you know that it won't break until there is a new edition, and you can expect that new edition will be a in a couple years. That's better than some languages.
How does that conpare to C?
The 2018 C standard didn't add anything that wasn't already in the 2011 standard, just fixed some bugs.
The 2011 standard added things vs the 1999 version, while maintaining backwards compatibility generally with even the 1989 version.
No breaking changes since 1999, and few since 1989.
Compared to "it'll only break every two or three years". There is a difference.
Now sure that means that for C programmers, the new hotness needs to be in new libraries, not directly in the language. So there is a cost to stability.
Re: (Score:2)
Re: (Score:2)
Good point, though it's deprecated in C99 (Score:2)
Ypu make a good point about gets().
Though, it really never should be used. There isn't a case where getline() or fgets wouldn't be better.
Also, it was deprecated in C99, so that's over a decade of deprecation before it eas removed from the standard (but still supported by compilers).
Re: (Score:2)
So the Rust team ralks about it. What do they DO about it? Rust policy is that breaking changes will be done in new "editions", which will come out "every two to three years". So if you write Rust cose today, you know that it won't break until there is a new edition, and you can expect that new edition will be a in a couple years.
Yes, that is true, but the 2015 edition code can still be compiled with 2018 tool chain, and a library written in 2015 edition is ABI compatible with 2018 code. So, your code wont break. You will have the option of updating your 2015 edition code to 2018 edition code, and that happens via a tool which will make most of these changes for you. If there is a 2021 edition, the 2015 edition would still be supported.
Now, this has been true since the 2015 which is not very long. So they may not achieve this but it
Re: (Score:2)
So yeah Rust is backwards compatible although there is incentive to keep things modern because 2018 removed a
Re: (Score:2)
"The 1.0 language is referred to as 2015 edition. In 2018 they made breaking changes to the language but Rust is still backwards compatible"
how can you make breaking changes that's still backwards compatible?
In terms in Linux, either he specifies the 2015 version and everyone writes to that spec, or someone will come along with new version code that doesn't compile . It'll be like python 2.6, 2.7 and 3.,0 all in the same codebase after a few years.
Re: (Score:2)
Re: (Score:2)
Alas, kids fresh out of college don't understand how quickly 2-3 years passes.
It's pretty sad that 10-year compatibility was taken seriously in the 90's once the 8-bit era was done. Today, the computer industry is very mature, but things have to change and break every year.
Re: Stability (Score:2)
Re: (Score:2)
Summary itself says no... (Score:3)
Will 2020 Be The Year Of Rust In The Linux Kernel?'
Later on in summary...
But things are afoot, and these things take a long, long time.
So basically you are talking MAYBE 2030, not 2020...
Re: (Score:1)
So basically you are talking MAYBE 2030, not 2020...
Indeed checks out. Just like the year of Linux on Desktop.
Gosh I hope not (Score:1)
Highly unlikely. (Score:5, Insightful)
The problem with Rust is that there is only one compiler... and no language specification. As a result, Rust is exactly what it's project managers decide it is. This kind of uncertainty in a language is unlikely to be appealing to anyone but people who write Rust code already.
Why not use C syntax? (Score:2)
One of the reasons for the popularity of Java is that it uses C syntax even though its semantics are very different.
I took a look at some sample 3-4 line programs, and hoo boy, its syntax appears to be a fusion of C, Pascal and Visual Basic? What the heck is that all about?
I am COBOL-programmer old and experienced in using Pascal, but even I admit C has at least won the syntax wars, white-space driven Python notwithstanding. So why isn't
fn factorial(i: u64) -> u64 {. . .}
instead written
u64 f
Re: (Score:2)
Re: (Score:2)
Apparently, Rust draws on languages like Haskell, OCaml, and ML - pretty much all languages that no one uses except in academia. So I'd bet your initial reaction to the syntax is pretty typical of most professional programmers. We've all spent years (decades for some of us) getting used to C-style syntax, so it's hard at first to wrap your brain around something so different.
Re: (Score:2)
As for "let", it's arbitrary. Most modern languages with type inference have something like "let", "var" or "auto" with a similar purpose.
Re: (Score:2)
The problem with Rust is that there is only one compiler... and no language specification. As a result, Rust is exactly what it's project managers decide it is.
Indeed, but there is a process, and quite a formal one for deciding what Rust is. Adding a language specification just pushes the problem back one: C is, for example, what ever the specification project managers decide it is.
The reason for a specification is because it allows multiple competing language implementations to happen more easily. They can happen anyway (c.f. Python, for instance) but the other implementations always have to track a "main" one.
Is this a problem? Well, if the language is implement
Yes (Score:2)
When a headline ends with question mark it's a NO. (Score:1)
The answer is almost always a NO if a news headline ends with a question mark.
Yes, most definitely. (Score:2)
I was thinking more like rot, but yeah rust too. .. Ohh, you meant Rust the programming language? Nevermind.
Let's begin the safe language wars! (Score:2)
To Rust enthusiasts (Score:2)
Re: (Score:2)
Since Rust is so good for kernel development, why don't you just write a kernel in Rust, to compete against the Linux kernel?
Here you go: https://www.redox-os.org/ [redox-os.org]
Re: (Score:2)
Ada would be a much better choice (Score:1)
Re: (Score:1)
This will probably get a lot of negative comments but Ada is a much better choice than even C. It is more portable and addresses more reliability and security issues better than Rust. It is more portable than C and it has commercial compilers in addition to open source compilers. Using contract support provided by Ada 2012 and potentially using SPARK be even better.
SPARK? ADA? Lol.
Oracle hasn't made you mad enough to say FU to Spark? Besides, the life of sparc is fading away fast. I think Solaris will be dead in 2024 if I remember right. I should get busy making the tombstone for it. I was maintaining some machines for a Federal agency. I swear Oracle was doing everything they could to make us get off the platform. Including blowing away support for things like the T1000 and even more modern machines. In fact I have a T1000 under my desk I'm about to throw out. I'll p
Re: (Score:1)
Details!! (Score:2)
Try submitting a rust patch to kernel (Score:1)
Try submitting a rust patch to kernel for Linus to approve. I'm pretty sure Linus would repeat his words from 2013:
"There aren't enough swear-words in the English language, so now I'll have to call you perkeleen vittupää just to express my disgust and frustration with this crap."
Again with rust? (Score:1)
Seems like every couple of years or so we get this push to go with rust.
Put it into the Kernel? You want Rust in the kernel? LOL.
That Kernel? It's Rusty!
So many rust jokes.