Linux Developers Continue Evaluating The Path To Adding Rust Code To The Kernel

[marios]

Why are you commenting on stuff you don't understand, you are not even a programmer? Your concerns are FUD that has no bearing on reality. If Rust is a better language than C and it fulfills the kernels goals better than C does, they should use it assuming they can integrate it properly into the Kernel build.

Also C++ isn't Rust and Linus had valid reasons for hating C++ (i.e. it has exceptions which doesn't work well in Kernel) but thats not the case with Rust.

Why are you making assumptions about people you don't know, you are not even a fortune teller? Your assumptions are BS that have no bearing on reality. If Rust is a better language than C and it fulfills the kernels goals better than C does, they should write another Kernel (call it Rustux or whatever you want) in Rust from scratch assuming there is good evidence that Rust is strictly a better language than C (there is no good evidence yet) (Adding new languages to critical parts of an existing project will just make the code unreadable to the developers that don't know the language).

Also C++ programmers aren't C++ and Linus might have had valid reasons for hating C++ programmers and the same (or similar) reasons might apply to Rust programmers.

[Isedonde]

If Rust is a better language than C and it fulfills the kernels goals better than C does, they should write another Kernel (call it Rustux or whatever you want) in Rust from scratch [..]

That pure Rust kernel project already exists ("Redox OS") and seems to make some impressive progress.

That doesn't change anything about the fact that it might be worthwhile for Linux to consider implementing some new stuff in Rust. Rust projects tend to be more secure and generally have less bugs compared to C projects, but Rust also has known deficiencies (like longer compile times and a steeper learning curve, which might actually be a good thing for kernel work, maybe you don't want absolute beginners to work on your kernel – also Rust is a "moving target" and the language itself has some mostly backwards-compatible changes now and then).

I've done some projects in Rust and I think it can be a great choice for a kernel to ensure high-quality code.

[mdedetrich]

Also C++ programmers aren't C++ and Linus might have had valid reasons for hating C++ programmers and the same (or similar) reasons might apply to Rust programmers.

Except that they won't. None of the reasons why Linus dislikes C++ applies to Rust.

Also unlike you I am not speaking on "behalf" of Kernel maintainers. I am pretty sure the Kernel dev's are mature and technical enough to figure out on their own if Rust is appropriate, no one needs your input on this.

Also the fact that it has gotten this far is promising, no other language (for reasons that are obvious if you know programming) fulfills the same goals that Linux kernel requires.

[marios]

Also unlike you I am not speaking on "behalf" of Kernel maintainers.

Says the guy that talks as if he knows exactly why Linus hates C++ programmers and talks as if he knows if the Kernel devs need my input. Also i never spoke "on "behalf" of Kernel maintainers". I just say my opinion.

To me the fact that Rust has gotten this far is not promising, it is just evidence that Linus has lost his former glory and became a conformist...

PS. The fact that I use words like "might" and "evidence" (instead of proof) means that my speculations are not certain facts.

[increasechief]

Unfortunately for Rust its borrow checker makes it too difficult to ship buggy code.

[kpedersen]

Unfortunately for Rust its borrow checker makes it too difficult to ship buggy code.

Luckily for Rust, Microsoft has shown an interest in it, so I am sure they will find a solution to enable their code to remain buggy and low quality

My guess is that they will add an extension to continue returning sodding raw pointers from all of their defective APIs like a bunch of amateurs.

Just like Microsoft has single handedly managed to convince the world that a 32bit OS can only ever allocate 4gigs*, they managed to convince the world that C++ has manual memory management.

* Whilst simultaneously selling a less crippled 32-bit server version with no such artificial restriction. These guys are on a roll!

[jp78]

There are better options that are more stable like SPARK.

[bug77]

Unfortunately for Rust its borrow checker makes it too difficult to ship buggy code.

If only concurrency was the only source of bugs...
But it is the source of the most costly ones, so, like I have said before, even if Rust fails, whatever system programming language we'll see in the future, it will certainly take some pages from Rust's book. In the meantime, Rust seems to be doing just fine. It's not taking the world by storm, but it sees its adoption increasing every year.

[mdedetrich]

If only concurrency was the only source of bugs...
But it is the source of the most costly ones, so, like I have said before, even if Rust fails, whatever system programming language we'll see in the future, it will certainly take some pages from Rust's book. In the meantime, Rust seems to be doing just fine. It's not taking the world by storm, but it sees its adoption increasing every year.

Concurrency bugs are definitely some of the hardest bugs to track (I have wasted probably weeks of tracking such bugs personally). Memory related bugs are also some of the hardest to track as well which is why they so often get overlooked in context of security issues.

No one is saying that Rust magically solves all bugs, however it generally makes the hardest bugs to track a compiler error (which in turn makes other types of bugs easier to deal with because there is less going on).

[increasechief]

One word: R/W locks