So, it appears that a LOT of effort is needed to get Rust into the LInux kernel. A _LOT_.

Question: what is the 'bang for the buck' expected at the end of the process?

In comparison, Microsoft has spent a GREAT DEAL of effort re-re-redesigning the user interface. Let's suppose they had LEFT IT as it was for Winxows 7, but then spent a BUNCH of time making improvements needed for touch screens without breaking the keyboard+mouse NOR the hotkeys NOR the UI that people were now very familiar with. They COULD have made the kernel SO robust that patches would no longer have to be deployed weekly. OK maybe not but still.

NOW we have a significant amount of Linux kernel dev time dedicated to folding RUST into it, and THEN having to MAINTAIN it.

In My Bombastic Opinion, there may be BETTER ways to spend this time, maybe more code reviews and performance tweeks? And maybe we could use some really good open source video drivers for various adapters (for XOrg, naturally, why waste time on Wayland).

I once again cite Arthur C. Clarke's "Superiority"

[1]http://www.mayofamily.com/RLM/txt_Clarke_Superiority.html

[1] http://www.mayofamily.com/RLM/txt_Clarke_Superiority.html

Question: what is the 'bang for the buck' expected at the end of the process?

Three possibilities spring to mind:

1) it turns out that rusty code is no easier to write and/or slower to run. Over time, take-up is minimal and eventually the support is dropped. As a result, we now have a better idea of the properties that a language must have if you want to write a kernel.

2) The opposite. Over time, more and more of the kernel gets rusty and eventually the kernel is just some assembly language routines propping up a lot of rust. As a result, well, same as before except it is C that no-one ever uses again.

3) Something in between, with each language having a well-defined role for different kinds of kernel component. As a result, no-one ever tries to write a kernel without multi-lingual support designed in from the start.

Whatever the outcome, I'm pretty sure we're going to learn something fairly important about how to write an OS. I'm also fairly sure that lesson will carry over to a few other large software projects.

Possibility number the fourth:

The next language du jour will displace rust in the fanboi's fancy before rust works properly with GCC, making this yet another footnote in the annals of computing.

No, mainline kernel development is not moving to llvm/clang any time soon.

I think the bang for the buck is kernel work that would be lost without rust support. It is yet to be seen if the cost of supporting rust will be worth it, but I am guessing it will. Linux isn't a single entity managed project, so you have to be flexible about working with others.

So what you are saying is that the Kernel will gain devs who refuse to code in anything but rust ... and this is a fine example of flexibly working with others?

I mostly don't see how there's much argument about it. I'm not writing any kernel contributions, so I just watch from the outside. Clearly they think it is interesting... I'm curious about the possibilities. Linus tends to be conservative and sometimes counterintuitive on some restrictions, so I am mostly depending on him when he allows something vs denies it.

Try it, writing rust is fast, real fast. Interop with C is great.

There is plenty of evidence to back up the "fearless" claim.

If you don't like it, go back to C, because its going to be a while before they let you write Perl in the kernel. ;)

"If you don't like it, go back to C, because its going to be a while before they let you write Perl in the kernel. ;)"

systemd-cpan

Interop between c and rust is great, far better that other languages

That may be so, but a homogeneous codebase (i.e C everywhere) is still easier in this regard. No bindings needed at all.

C++ being a 99% "superset" of C kind of achieves this but there are a few other issues.

That said, much of the AMDGPU drivers is C++ and it seems to integrate OK with the rest of the kernel.

C interaction with C is better.

> 'There are possibly some well-designed and written parts which have not suffered a memory safety issue in many years. It's insulting to present this as an improvement over what was achieved by those doing all this hard work.'

This is just silly. Yes, most of the kernel has been painstakingly scrubbed of memory safety issues, but there have been tons of them and there are many more lurking. I used to write in assembly language - I don't any more (once a year or so) because I can use C#, Rust, or Python and get literally 100x times as much work done in the same amount of time without worrying if my JMPing is idempotent. It's not an 'insult' to my past self to admit that assembly language programming is a touchy, dangerous, pain in the ass. Good for me for having been able to do that, but thankfully it's rarely necessary any more.

Similarly, it will be great to know that future kernel drivers, and maybe more significant parts, written by other people who are not as awesome as me (tongue -> cheek) can be guaranteed free of memory safety issues. This is indeed a giant improvement. So kudos to the guys who did it in C (including me!) while keeping memory safe, but they're not going to be 'insulted' by making it possible to go from banging two rocks together to hammers.

Methinks you miss the point. The fact that the kernel has, as you say, been painstakingly scrubbed of memory safety issues, is indeed the result of necessary "hard work". That hard work included (and continues to include) extreme care, planning, and discipline to prevent propagating those same errors in future work. Now comes the next panacea-du-jour, "memory-safe" languages (air-quotes intentional), because the next generation of "coders" can't be arsed to develop the discipline, do the planning, and execute the extreme care because, well the "compiler will do all that for me". Except it won't in all cases. So the ongoing development will be dumbed-down with the "practitioners" counting on an imperfect tool to be perfect. We all know how that will end.... 1

Perhaps "insult" was too strong a term. But the impending deterioration of developer skills deserves some form of epithet to properly label it. My suggestion: s/insult/pathetic/

1 cf. garbage collection as the panacea for object and heap management; and of course, the Tesla "autopilot".

I think the hubris of the rust devotes is both pathetic and insulting.

Things is when you write kernel C you don't have libc, it the syntax but not the language you are used to, so you have to write a lot of code you would otherwise use a library for yourself. Having a lot of help from the compiler is necessary.

Rust is like -Wall on steroids, it's not hubris, it's the exact opposite: it's acknowledging that you are not invincible and you need help from the compiler.

This much-hyped memory safety is a bit of a red herring when it comes to compiling Rust code. For sure, the language doesn't allow many risky C type operations. But ultimately it's got to be compiled into machine code, and both CLang and GCC break down source code written in any supported language into lower level representations before the machine code is generated. And then there's a subsequent optimisation phase if you want it. So whilst it might offer less risky operations at the source level, there's no way a language can actually guarantee memory safety after compilation.

> there's no way a language can actually guarantee memory safety after compilation.

I don't think you understand how things work.

Dont understand? Really? Can you guarantee that a Rust front end for the GCC would always generate memory-safe GIMPLE representations for every possible Rust expression? That's not a function of the Rust language (which I find likeable, with many good ideas in its design), but of the compiler implementation, so my point that memory safety can't be guaranteed by language design alone is pretty straightforward when talking about the GCC, which generates all its machine language from GIMPLE, not direct from source code.

Rust does not guarantee memory safety, it helps you write memory safe code. It gives you enough rope to hang yourself should you want to.

It's very easy to write safe rust, and for it to be obvious that it it is safe. Independent of the compiler or target arch.

It's safe even when multi threaded. That's pretty clever it's almost impossible write multithreaded c that is _obviously_ safe. Multithreaded rust is as easy as single threaded rust because single ownership works across threads.

Rust _is_ pretty cool. It's not just the memory safety, also the ability to write test code along side production code and documentation code that you know compiles and is correct too. It's number system is strangely convenient too.