Linus Torvalds On Where Rust Will Fit Into Linux (zdnet.com) 115
An anonymous reader shares an excerpt from a ZDNet article, written by Steven J. Vaughan-Nichols: Linux is the poster-child for the C language. But times change. The Rust language has been slowly gathering support for use as a system language in Linux. For example, at the 2020 Linux Plumbers Conference, developers gave serious thought to using the Rust language for new Linux inline code. So, where is it today? I asked Linux's creator, Linus Torvalds, and the Linux stable kernel maintainer Greg Kroah-Hartman for their thoughts. [...] What does Torvalds make of all this? He's in "the 'wait and see' camp -- I'm interested in the project, but I think it's driven by people who are very excited about Rust, and I want to see how it actually then ends up working in practice." "Personally," Torvalds is "in no way "pushing" for Rust, [but] I'm open to it considering the promised advantages and avoiding some safety pitfalls, but I also know that sometimes promises don't pan out."
Torvalds thinks "Rust's primary first target seems to be drivers, simply because that's where you find just a lot of different possible targets, and you have these individual parts of the kernel that are fairly small and independent. That may not be a very interesting target to some people, but it's the obvious one." Another point is taking on drivers first for "any initial trials to drivers is simply the architecture side," said Torvalds. "Lots of drivers are only relevant on a couple of target architectures, so the whole issue with Rust code not being supported on some architectures is less of an issue." Kroah-Hartman agrees that "drivers are probably the first place for an attempt like this as they are the 'end leafs' of the tree of dependencies in the kernel source. They depend on core kernel functionality, but nothing depends on them."
Torvalds knows some people don't like the idea of Rust in userspace at all. "People complain[ing] about "Rustification" in userspace isn't a great sign for any future kernel use, but hey, we'll see. The kernel is different from userspace projects -- more difficult in some respects (we use a lot of very odd header files that pushes the boundary of what can be called "C"), but easier in many other respects (mainly in the sense that the kernel is fairly self-contained, and then doesn't rely on other projects for the final binary)." From where Kroah-Hartman sits, "it will all come down to how well the interaction between the kernel core structures and lifetime rules that are written in C can be mapped into Rust structures and lifetime rules for drivers in Rust to be able to use them properly. That's going to take a lot of careful work by the developers wanting to hook this all up and I wish them the best of luck."
Torvalds thinks "Rust's primary first target seems to be drivers, simply because that's where you find just a lot of different possible targets, and you have these individual parts of the kernel that are fairly small and independent. That may not be a very interesting target to some people, but it's the obvious one." Another point is taking on drivers first for "any initial trials to drivers is simply the architecture side," said Torvalds. "Lots of drivers are only relevant on a couple of target architectures, so the whole issue with Rust code not being supported on some architectures is less of an issue." Kroah-Hartman agrees that "drivers are probably the first place for an attempt like this as they are the 'end leafs' of the tree of dependencies in the kernel source. They depend on core kernel functionality, but nothing depends on them."
Torvalds knows some people don't like the idea of Rust in userspace at all. "People complain[ing] about "Rustification" in userspace isn't a great sign for any future kernel use, but hey, we'll see. The kernel is different from userspace projects -- more difficult in some respects (we use a lot of very odd header files that pushes the boundary of what can be called "C"), but easier in many other respects (mainly in the sense that the kernel is fairly self-contained, and then doesn't rely on other projects for the final binary)." From where Kroah-Hartman sits, "it will all come down to how well the interaction between the kernel core structures and lifetime rules that are written in C can be mapped into Rust structures and lifetime rules for drivers in Rust to be able to use them properly. That's going to take a lot of careful work by the developers wanting to hook this all up and I wish them the best of luck."
A couple years back it was C++ (Score:4, Informative)
I still remember when they added C++ to the kernel. They had the same arguments and it never went anywhere.
Like C++, Rust is a different way to structure (Score:2)
As I understand it, Rust does not like pointer structures because it does not have garbage collection. (I am talking about things like linked lists, not simply owned pointers like strings and vectors.) So rust encourages array lists instead.
I would expect the C based kernel to be riddled with pointer structures. In which case it is difficult to see how that could be converted to rust unless lots of unsafe code is written.
It is a bit like you can have C with Classes, but real C++ uses RAII which is a diff
Re: (Score:2)
Re: (Score:2)
Indeed. I suspect so much of the kernel code that would be written in Rust would be declared inside "unsafe" blocks that there'd be little point using over C or C++ in the first place.
Re: Like C++, Rust is a different way to structure (Score:2)
Unsafe in rust doesn't make it as unsafe as c, in fact it retains a lot of safety features. For one thing, the borrow checker is where rust gets a lot of its memory safety, and that still remains fully intact no matter what you do.
Re: (Score:3, Insightful)
That's the primary problem with Rust and similar languages - they can't actually interface with anything, especially not hardware, without writing unsafe code. And every language with those sorts of goals has run into those problems from Perl to Ruby to Rust, at some point, you have to declare an unsafe structure safe and cross your fingers that you didn't forget an edge case.
Hence those languages still don't really have native GPU/OpenCL/CUDA support without some major hackery or simply having wrappers at
Re: Like C++, Rust is a different way to structure (Score:3)
You'll probably use unsafe at some point, but most of your code doesn't need to be unsafe.
Re: (Score:2)
You can easily use pointer structure style code without a garbage collector..
It is indeed easy to write code to manually manage pointers; the hard part is to write it correctly (without introducing memory-leaks, read-after-free errors, and other undefined behavior). And even if you're a seasoned expert in manual object-lifetime-management who never makes a mistake, the junior developer who comes after you to maintain your code probably won't be, so he's likely to add the bugs you carefully avoided. Either way the end-result is buggy code and exploitable security flaws that might h
Re: (Score:3)
It's a good argument, but it doesn't apply if you need to be using unsafe code to do the job. And the argument is that you always will be in the contexts that would have the unsafe code anyway.
This isn't a flawless argument, and I can imagine that Rust might well cut down the problems. But the documentation is so bad that I can't be sure.
Re: Like C++, Rust is a different way to structure (Score:2)
It still applies in unsafe code, albeit to a reduced extent. Even so, you don't have to write an entire driver as unsafe.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Another issue is knowing when it's safe to dereference and when not, and in many places in the kernel, this can change during the lifecycle of the object. On NUMA systems, for example, pages are calculated relative to a given node's pgdat, which may become unavailable at runtime when a node goes offline, resulting in any subsequent pointer dereference triggering an unhandled page fault (the same also holds true for memory banks that may have been set into self-refresh, or in the case of power-managed memori
Re: (Score:2)
It's possible with inline assembly in volatile blocks, which is sort of a workaround, but yes, these parts are generally better done in assembly directly. Especially on architectures that like to reorder instructions.
So, all of it (Score:2)
I note that what a driver *does* is interface with the hardware and the OS. That's pretty much the entirety of what a driver does - takes messages from the OS and pass them along to the hardware and vice-versa. So ...
> your use of unsafe code would be confined to explicit interactions with the rest of the kernel / hardware
So the unsafe part would just be the driver part of the driver. :)
In other words, the whole thing, pretty much.
Re: (Score:2)
Re: (Score:2)
Except that those structures often must be pinned down to physical pages and handed over to the driven hardware. If you prematurely unpin the page, the hardware may read whatever random thing gets stuck there next or overwrite it.
The rust runtime can't do anything about that because it has no model of the hardware.
Re: (Score:2)
And Rust doesn't have a "runtime" per se. It has stdlib which is analogous to the standard C/C++ libs. When you write something
Re: Like C++, Rust is a different way to structure (Score:2)
Actually rust still manages the lifetime in unsafe. Unsafe does not let you ignore the borrow checker. Also pointers aren't necessarily unsafe, rust has many safe pointers (the documentation refers to them as smart pointers.)
Re: (Score:2)
There is a *huge* difference between C++ and Rust. Rust is designed from the ground up to be a safer language by enforcing memory-safe constructs. C++ is even more complex than 'C' and thus gives you much more rope to hang yourself with a more complex design, timing, messaging, and threading issues. Most security bugs like pointer use after free come from the more complex design that C++ adds to a project. Rust simply puts security and code safety first. C++ not so much.
SystemD already takes care of everything? (Score:2, Funny)
So why do we need a newbie like Rust?
Re:SystemD already takes care of everything? (Score:5, Funny)
IN a few years, systemd will have a Rust replacement called rusted and it will patch your kernel by default.
Re: (Score:2, Redundant)
IN a few years, systemd will have a Rust replacement called rusted and it will patch your kernel by default.
Often in ways that you may not have asked it to, and with little regard to the stability of your system.
Re: (Score:3, Funny)
Nah, kerneld will hot-install itself as a kernel extension, then rewrite all hooks to point to itself - sidelining the original. Any modules or extensions Poettering finds difficult to deal with will be disconnected from kerneld, and their on-disk version overwritten with NOPs to prevent future problems.
Re: (Score:2)
Any modules or extensions Poettering finds difficult to deal with will be disconnected from kerneld,
Well hopefully kerneld will get sound drivers soon and then it can take over from pulse. I'm sure with new eyes it will be better than last time!
Flamebait? Seriously? (Score:2)
Is that you Lennart?
Some people really need to get a fscking sense of humour.
Re: (Score:2)
Say what you want about it but systemd? Is something that is required, absolutely required for large multi system environments.
Wrong.
Re: (Score:3)
Re: (Score:2)
Thought it was because they wanted to ship Gnome and Gnome requires systemd (hell, IIRC Gnome started systemd.)
Re: (Score:2)
Good practices (Score:5, Insightful)
As many would say, good practices are the key to good code. You alloc some memory/you need to init it, you pass a pointer/you need to check for null, you call something that could fail/you check if it failed. However, as much as we all espouse these virtues, we all are only human. Additionally, there's more and more demand to add more and more complex functions into devices and the drivers, timelines created by people who don't understand code, and so on. All of these conspire to work against good code.
And it's this that I think is where Rust has a chance. Are you calling a function that could fail? More than likely it returns a Result<T, E>, which means you have to write code for Ok(T) and Err(E). If you don't, the compiler will not give you a binary. There's no shortcut, you must fulfill that minimum amount of work or you need to flag it with ? to send the matter back up the stack (the not my problem solution). However, finding the places where someone has passed the buck is incredibly easy in a code review, so there's only so long one can hide there. Playing fast and loose with memory? The compiler checks the lifetime of the variable and if you start using the variable outside it's lifetime, you either have to handle that there and then or you don't get an executable file.
I think that's the neat thing about Rust. The compiler enforces what I would call good practices from the get-go. Is it a cure-all? Hell, no. You can still do dumb things with Rust. But some of the more obvious, that we all think wouldn't or at least shouldn't happen in drivers, the Rust compiler is quick to figure it out and slap your hand for it. The con of this? Your program is more verbose. That's because you cannot just ignore the fail case, you cannot just allocate and assume it's there, you cannot just grab memory deref it and assume it's all good. The compiler will ensure that you've coded cases for failures along the way and that you meet the minimum implementations of traits. You've got to think and the compiler is there to ensure you do think for a lot of dumb cases.
However, I'm not one to proselytize people into Rust. C is still a damn fine language. But I think device drivers are a very good target for Rust. Maybe not all, but a lot. I think the compiler pointing out problem areas for you to ponder over would benefit device drivers. Again, C is incredibly good, but I can absolutely see an area that Rust could fill into. Now arguments about having C and Rust all mixed in, those I can very much understand. And I would say that's a good point for the opposition towards Rust.
Ultimately it's up to the device driver maintainers to do what they please. But I feel there's absolutely a conversation to be had about some Rust in drivers.
Re: (Score:1)
Re: (Score:2)
which means you have to write code for Ok(T) and Err(E).
_ => {}, problem solved?
Re:Good practices (Score:4, Insightful)
A better argument would be that drivers tend to be where most new programmers get introduced to the kernel, and they're often hastily cobbled together by device OEMs with varying 'quality'. Languages that can help the aspiring programmer not shoot themselves in the foot can, in theory, be useful here. There was also an attempt some 20 years ago to extend the GNOME ORB into the kernel so you could effectively implement drivers in userspace in perl or some other abomination of a language allowing each side to call each other's objects via CORBA. Many of the same arguments were used at the time, and that also predictably went nowhere.
The fundamental problem is that driver developers don't stay driver developer's forever. Eventually they will start to knock-up against limitations in the subsystem or in some other part of the kernel needed by their driver, and they will have to branch out and figure out how to make these changes. They will sooner or later have to learn how to write safe code that is used to many other architectures and systems with incredibly different performance characteristics and caveats (especially concerning memory models) that one always needs to keep in mind when modifying common code, and for things like this, the toy language of the month isn't going to cut it.
Proof in pudding. (Score:2)
Sounds like a safe position when you consider the history of up and coming languages and their adoption...or lack of.
Rust would have to run anywhere Linux runs... (Score:3, Insightful)
At this time, it is a very limited, single-source language, while Linux runs on tons of hardware. Hence at this time, no chance for anything but a meaningless stunt. Rust is, at best, a nice tech-demo at the moment with a bunch of very vocal blinded cult-like followers that probably believe (mistakenly) that they will finally be able to write good code using it. The actual reality is that the language matters very little for that.
In case you missed it in the summary (Score:4, Informative)
Torvalds thinks "Rust's primary first target seems to be drivers" ... "Lots of drivers are only relevant on a couple of target architectures, so the whole issue with Rust code not being supported on some architectures is less of an issue."
That seems like a reasonable and pragmatic approach to trying Rust out in the Linux build. Maybe it will be successful which will make Rust more attractive to more architectures otherwise the existing drivers written in C will continue to be used. No harm, no foul,
Re: (Score:1, Interesting)
Seriously, Rust-fanboy?
Why, I ask myself, is Rust as you say "very limited"?
Maybe because it's useless? I mean, we have a plethora of coding languages...
Now, I ask you: why to add another f*cking language to a f*cking--complex-by-itself kernel? Are you really glad that the programmers now need to learn another language and have to use another debugger too? And have to search for bugs in the compiler in a myriad of hardware?
I go the other way around: remove all languages except one.
Re: (Score:2)
Rust is "very limited" because it depends on a Clang compiler being available and has poor documentation. The second can certainly be fixed. And Clang can be implemented across more platforms. So the problems CAN be fixed. Whether and when they will be is another question.
P.S., when you say "remove all languages except one" do you mean do everything in Ada or do everything in Eiffel? (I once wrote an Eiffel driver for my personal use, so that's not totally impossible. Of course, Eiffel has changed a b
Re: (Score:1)
The problem I mentioned can NOT: you add another language the programmers need to learn, another debugger and another compiler for each hardware platform with their own set of bugs.
Ain't the kernel hard enough that we have to add another useless language on the coders?
Also, I would choose C over Ada or Eiffel. For obvious reasons, alongside assembly (or any other low-level language).
Re: (Score:2)
Well, Ada and Eiffel were jokes, but I think one actually could to an implementation in Java fairly reasonably, but you'd need to write a Java compiler that targeted the hardware level rather than the JVM. ISTR that someone did that a decade or so ago, and about a decade before that someone did a special purpose custom CPU that implemented the JVM .(Well, pretty much. It was a subset implementation with a macro assembler that could have been extended to handle the rest of it, though I don't know if this e
Re:Rust would have to run anywhere Linux runs... (Score:5, Insightful)
Indeed. Rust is now officially supported (Tier 1) on only x86, x86-64 and 64-bit ARM. Rust on other hardware should be considered experimental.
Linux has official support for a lot more hardware because of the existence of compliant C compilers for those platforms. .e. anything but device-drivers specific to the platforms that Rust supports), the compiler would need to have Tier 1 support for all hardware that Linux does, and I don't see that happening (at least in any other way than Linux dropping support).
Therefore, it is quite evident that for Rust to be used in any portable part of the kernel (i
Rust, being so much of a hipster cult (I'm sorry, but it's true), is not likely to care about old hardware platforms like Linux developers who introduced support for them decades ago when they weren't.
Re: (Score:2)
Well, the support would come if somebody wrote a rust-backend for gcc.. But yeah, I don't see that happening, and it would expose just how unstable the language is (unstable as in changing) ;)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
> a very limited, single-source language
Linux has always (so far) only officially built on gcc.
llvm is coming after thirty years but being locked into gcc is not traditionally a concern of this community.
Most of the big open source languages have a single implementation that nearly everybody uses. C/C++ are an exception in that regard.
Re: (Score:2)
Java has always had multiple implementations - Sun javac, IBM jikes, IBM/Eclipse ecj, GNU gcj. FORTRAN and Ada have multiple implementations. Hell, even JavaScript has a number of implementations floating around.
Re: (Score:2)
Well, he said "that nearly everybody uses", and that's not true for things like Jython or JRuby. They exist, but they're definitely minority usage. And Java was only Sun Java for at least the first 5 years, probably longer, so not "always had multiple implementations".
That said, multiple compatible implementations is certainly that most common state. Pypy tries to maintain compatibility with Python , etc. But note that the different implementations will often, perhaps always, differ slightly in what the
Nice tech-demo (Score:2)
A "tech-demo" which is adopted by "tech-giants" like Microsoft, Cloudflare, Facebook, Amazon, etc.
Re: (Score:2)
> a nice tech-demo at the moment with a bunch of very vocal blinded cult-like followers A "tech-demo" which is adopted by "tech-giants" like Microsoft, Cloudflare, Facebook, Amazon, etc.
Also Google. Android is adopting Rust (example [googlesource.com]). Many other projects, both internal-only and externally-visible, are doing so as well.
Re: (Score:3)
At this time, it is a very limited, single-source language, while Linux runs on tons of hardware.
Linux runs on many obscure platforms, but the vast majority of Linux devices run on only a few platforms. If Rust proves to work well in practice for kernel code, it will become the responsibility of the people who care about the obscure platforms to ensure that LLVM supports them or they'll be left behind. I'm not saying this is what will happen, but if Rust proves to be as effective as it has the potential to be, the kernel will undoubtedly choose to move forward at the expense of obscure platforms.
Hence at this time, no chance for anything but a meaningless stunt. Rust is, at best, a nice tech-demo at the moment with a bunch of very vocal blinded cult-like followers that probably believe (mistakenly) that they will finally be able to write good code using it. The actual reality is that the language matters very little for that.
You're
Re: (Score:2)
The difference between you and me maybe that I have seen countless hypes of the type "Tool/language/approach XYZ will finally fix software errors!". None of them ever has panned out. Assembler code was not more error prone than C and C is not more error prone then Rust. The reason to use C and not assembler is portability and higher productivity. But in a kernel-setting, things end there. The amount of control C gives is _needed_.
Re: (Score:2)
Assembler code was not more error prone than C and C is not more error prone then Rust.
Do you have som proof for this? Because otherwise it sounds like nonsense. There is a class of wrong programs which are possible in assembler and are not possible in C (e.g. programs having all the type mishmash errors C compilers catches). That means a programmer can make more errors in assembler than in C. That almost definitely means there more errors in assembler than in C provided that the scope of implemented functionality is the same.
Relationship between Rust and C is analogous to the one between C a
Re: (Score:2)
Why do you assume more ways errors can be made results in more errors? There is no sane reason for that assumption. Coding is not a randomized process.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You cannot keep a reference to an object which is out of scope in Rust without sneaking it out using unsafe casts. The fact that C++ and Rust use the same back end does not have any influence on this. Rust front end translates to LLVM assembly. That is much lower level type system than C++. It is just an assembly with types. Life time management was already done by the front end and its preservation is enforced by data dependencies in the generated LLVM assembly. Low level optimizer and machine code generat
Re: (Score:2)
Yes, and while I'd say the bias in theory should be minimal your point is not entirely incorrect. So, I took a look at CVEs for the three projects and noted the following, for the preceding four years (the same length as now being compared with rust/c++):
I applaud your attempt to put this discussion on a factual basis. Unfortunately, CVEs are not a good way to measure security vulnerabilities. There are many CVEs that are incredibly narrow, while many others are incredibly broad. The number of CVEs filed against a particularly component depends heavily on researcher interest, and where CVEs are reported by developers, on developer focus.
I hate to simply argue that your analysis is useless without providing something better, but the truth is that systemati
Um ... (Score:5, Informative)
Linux is the poster-child for the C language.
Other than Unix, for which C was (basically) invented.
Re:Um ... (Score:5, Funny)
Rustification? (Score:3, Interesting)
Rustification? We are missing an opportunity here to call it rusting! Rusting!
I logged in especially to post this comment. :P
I'm all for safer code, but it will be a mammoth task to get the linux kernel completely rusted up. So, from the outside in, and over a long length of time seems to be the only sane way to do it. :)
Re: (Score:3)
Re: (Score:2)
Watch out or the Rust devs will start working on an interface for that GPU-acceleration library.
Re: (Score:2)
And if the experiment fails, the offending code will be rusticated.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Linus is correct on the promises don't pan out (Score:3)
Look at the Microsoft ecosystem. More and more of it has moved .Net CLR. As far as recent Exchange version internals, I have no idea but in any case the recent vulnerabilities were not the sort that arise for uninitialized variables, buffer size / bounds checking issues, or memory leaks. The impact - huge.
The simple fact is ASLR/DEP on at least x86_64 platforms has pretty much address the exploitability of these issues in most case. There are still areas and "kernel space" is probably an example where some of those rules go out the window, and yes occasionally people manage to find what they want with egg hunters etc and develop working exploits anyway. However looking at things like the schannel bugs, and msdns issues - even though MS admitted they could lead to RCE - nobody has come up with POC code that does anything beyond cause a crash.
The more serious security issues we face today are problems that exist in higherlevel logic and can't be addressed by sprinkling in bounds checking/gc/required initialization etc - if they could the Java eco system would have been squeeky clean in terms of exploits and for 'security' using Java would have become an industry mandate 20 years ago - did not happen. Rust won't really solve anything either.
Re: (Score:2)
I have no idea but in any case the recent vulnerabilities were not the sort that arise for uninitialized variables, buffer size / bounds checking issues, or memory leaks. The impact - huge.
Worth mentioning that Microsoft switched away from many default standard library methods that are hard to use safely (like strcpy or strncpy) and implemented their own that are easier to use.
The simple fact is ASLR/DEP on at least x86_64 platforms has pretty much address the exploitability of these issues in most case.
Yeah it's time to give up the idea that most security bugs are from memory issues.
One thing I wonder (Score:2)
Regarding Linus' comment of "we use a lot of very odd header files that pushes the boundary of what can be called C" -- I've wondered for a while, why do they even bother using standard C?
Eg, you sometimes see discussions about how volatile doesn't do what you want, or how GCC might optimize something in an inconvenient way. So why do the work of working around the compiler when GCC could have a "kernel-mode" flag to turn on whatever settings are most convenient for kernel development?
I suppose Rust in the
Re: (Score:2)
I've wondered for a while, why do they even bother using standard C?
They don't use standard C. The kernel developers happily use and abuse any extension GCC will give them.
Many different tools, some fads lasts others fail. (Score:1)
Re: (Score:2)
I have the belief that we should use the best tool for the task. What does Rust solve?
It allows developers who know nothing about the language or even much competency to write code without buffer overflows.
Re: (Score:2)
Perhaps one should know what is going on under the hood if you are working on such critical pieces of infrastructure.
I agree with you, but that's not going to happen. The authors of the core kernel mostly know what they are doing, but the driver writers very often are low-paid newbies. It would be nice if they were protected.
This Guy Again (Score:2)
He spends half of his career nit picking C++, then immediately jumps on the hype train when a clone language of it becomes popular.
Yeah, it's the religious aspect that worries me (Score:1)
Proposing a better language than C, that has things built-in and guaranteed, that really should have been automated away a long time ago, and are stupid to manually keep track of all the time, is a good thing.
But the blind, almost militant, "thou shalt not insult my deity [read: me] by not embracing it" ideologist flag-waving mindset that comes with certain ... communities... is a cancer that you can't get rid of anymore, once you fed it once. It will take over everything, and be aggressively offended if yo
xcuse me for scribblin' but (Score:1)
rust is that , does that mean i will get like "forgot to press tab"-error in line 90 in olders bash scripts ?
there i thought at least an OS was still written in primal opcodes , so nothing is further from the truth then
Re: (Score:1)
Re: (Score:2)
If they are only writing drivers in Rust, then programming language (ie, CPU execution speed) is unlikely to be the bottlneck. Most of the time will probably be spent waiting for the hardware.
Takes too long (Score:1)
With Linux there will always be a huge number of C diehards unwilling or, worse, resisting the changeover to Rust, not the least of which included Torvalds himself.
Question: (Score:2)
Re:Computer Hardware Executes Machine Code (Score:5, Insightful)
The only possible way you could think this is an informed, illuminating thing to say is to be uninvolved in the process of creating software. It matters what language you write the source code, because people write the source code, and different languages allow people to produce different machine code differently. It's like saying it doesn't matter what you build the airplane with, as long as it flies. If building an airplane that flies is your only goal, you're useless to the world. We've moved on to how to produce better, safer airplanes more easily and reliably.
Re:Computer Hardware Executes Machine Code (Score:5, Interesting)
Not quite: You need the BumFuck compiler to be supported as FOSS on all the target platforms or at least an alternate implementation of the BumFuck language to be available, as FOSS, long-term on all relevant platforms. Now, Rust has not even a stable language definition at this time an it certainly has no good reliably long-term maintained FOSS implementation over all relevant platforms. That basically makes it a very stupid choice for anything kernel-related that is relevant to more than some specific platforms.
My guess is Linus will just keep the Rust cult safely contained while he gives them enough rope to hang themselves.
Re: (Score:3)
My guess is Linus will just keep the Rust cult safely contained while he gives them enough rope to hang themselves.
or it can allow Rust to be stabilized in a form that will be useful to the kernel in the future. One just needs to look at Clang, which took years to be usable in the kernel because it didn't have the (GCC) features that the kernel needs. So the kernel developers looking at Rust before it's finalized is the best thing to do for both Rust and kernel.
Re: (Score:3)
I think Clang is part of what he's talking about. IIUC Clang doesn't run on all the relevant architectures, and Rust depends on Clang.
OTOH, my view is that Rust won't be widely useful anywhere until there is decent documentation. The current books on the language (last I checked...about a year ago) aren't adequate, and the web site is poor. Compare it with practically any other language Ada, Basic, C, C++, D, Erlang, Fortran, Go, (I'm not sure about Haskell), ... Rust is wildly inferior in documentation.
Re: Computer Hardware Executes Machine Code (Score:2)
The documentation seems pretty good to me. I have zero cs background whatsoever and had only been doing any programming at all for about a year and a half before picking up rust, and was able to do so with relatively little difficulty (I started with rust last September.) I've already done a few projects in rust, it's a pretty nice language to work with once you understand the ownership model.
Re: (Score:2)
I think Clang is part of what he's talking about. IIUC Clang doesn't run on all the relevant architectures, and Rust depends on Clang.
No, you're thinking of LLVM. Both Clang and Rust depend on it. They are both language front-ends to feed into the language neutral LLVM back-end. And yes LLVM supports a limited number of platforms compared to GCC. But not all kernel drivers run on all platforms either, which is one of the reasons why drivers are the first things being targeted with Rust.
OTOH, my view is that Rust won't be widely useful anywhere until there is decent documentation. The current books on the language (last I checked...about a year ago) aren't adequate, and the web site is poor. Compare it with practically any other language Ada, Basic, C, C++, D, Erlang, Fortran, Go, (I'm not sure about Haskell), ... Rust is wildly inferior in documentation.
That's throwing out the baby with the bathwater. Rust is new, there hasn't been enough time for the documentation to mature. For that mater, as mentioned i
Re: (Score:2)
We probably need to revisit the idea that certain hardware only runs on certain platforms. For example, I saw a nice hardware hack that attached PCI devices to an RPi.
Re: (Score:2)
And by the same token, we can revisit that Rust/LLVM doesn't run on platform XYZ. For example, LLVM recently added support for the m68k platform.
And compilers stop supporting some architectures (e.g.Armv2/v3 not supported by GCC anymore, and there were talks of removing Itanium as well). So maybe the Linux kernel shouldn't be using GCC?
But then the kernel drops support for some platforms as well. So maybe we shouldn't be using Linux, since we don't know how long it will support platform XYZ.
Sarcasm aside, e
Re: (Score:2)
At least when old hardware is dropped, you can still use the old versions of the software if you want to do some retro computing. It'll work as well as it ever did.It's much harder to deal with if the hardware was never supported.
I don't oppose the experiment, I just urge caution in assumptions of what platform might interface to what hardware.
Re: (Score:2)
At least when old hardware is dropped, you can still use the old versions of the software if you want to do some retro computing. It'll work as well as it ever did.It's much harder to deal with if the hardware was never supported.
The same applies to the drivers. If the driver already existed in C, you can still use that instead of the shiner Rust version. But from what I know of the kernel community, I doubt they would switch a driver to Rust unless Rust is supported on all the platforms that the existing driver supports (or they will support both old and new drivers in parallel)
And if the driver never existed, then you're not worse off if a new driver is written in unusable Rust. You had and still have a paper weight hardware.
Re: (Score:2)
OTOH, if it was written in C, it benefits more people. That's one of the trade offs that needs to be considered. Of course the developer has the right to choose as they will, they just need to know they're giving up a broader usefullness if they choose Rust. Thinking X device will never be connected to Y processor might lead to a less desired outcome.
Re: (Score:2)
if it was written in C, it benefits more people
Most people have Rust supported hardware. So there is more people who would benefit from the safer language than people who would benefit from C-only drivers.
they just need to know they're giving up a broader usefullness if they choose Rust
I doubt they are not aware of that.
And you're borrowing problems:
- Linux has not yet decided to use Rust, it's just an investigation on the technical feasibility of using Rust in the kernel and what it would look like. This is not an investigation, must less a decision, to use Rust for driver X or Y.
- As far as I understand it, the current targets are
Re: (Score:2)
Since one of the arguments in TFS and TFA was that some hardware won't be used on platforms Rust doesn't work on, yes it is useful to point out that that isn't necessarily true. Are you arguing that decisions made in ignorance are better?
I'm not fretting about this, I have quite enough to do myself without taking a soldering iron to less popular hardware to interface it with devices not made for it. But it is worth noting.
Re: (Score:2)
Note there is a project in progress to port Rust to GCC. I haven't looked at the code to see how it's going.
Re: (Score:1)
Global Warming would be solved if we just shot all the dumfuck assholes who blather without knowing what they are talking about in the head!
Why, how much CO2 are you emitting? Do you have your own coal plant to keep your bullshit warm?
Re: (Score:2)
> Global Warming would be solved if we just shot all the dumfuck assholes who blather without knowing what they are talking about in the head
Most people don't advocate that they themselves should be shot in the head.
As others have now pointed out to you, different programming languages are in fact different. The next time you're getting mad about "dumfuck assholes who blather without knowing what they are talking about", perhaps it will help to remember that you are in fact one of those dumfuck assholes