Linux Developers May Discuss Allowing Rust Code Within The Kernel

[jrch2k8]

You should discard it. Backporting specifically means taking a patch and adjusting it to work on an older version. Since that concept simply doesn't apply, I am going to assume you meant borrow ideas from Rust and reimplement it from scratch in C++. This isn't simple or really feasible at all without breaking backward compatibility in a major way. Efforts to even provide a weaker guarantee hasn't really gone anywhere

https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

C++ has definitely improved quite a bit but major redesigns are just not practical given millions of lines of existing code and the burden of carrying that forward

yeap, i mean it this way. (my english is not great today)

although i used to call this "reimplement it from scratch in" backporting back in the day(but in my language) since back then we worked with plain files and folders since patches weren't a thing until a long long while later, curiously this was also called something akin to "version manager" by some people because well git/CVS, etc. didn't exist either.

OH, the FTP -> zip source days ...

[wberrier]

Gonna have to side with RahulSundaram on this one... (in fact I was about to paste the same links about Linus being open to Rust: "people are actively looking at doing drivers and things that are not very central to the kernel, for example, in Rust. People have been looking at that for years now. I'm convinced it's going to happen one day.")

I can understand people being wary of "the hot new thing" since so many come and go.

Honestly ask yourself this question: if gcc/clang version x.x came out with some flags for warnings that would:

* warn about dereferencing invalid memory access
* warn about concurrently corrupting memory from multiple threads

would you refuse to enable these warnings? I understand there's an entire discussion about when and which warnings are are appropriate, which ones cause issues because the developer knows better, etc... But honestly, the trend seems to be towards adding/enabling more warnings...

The idea is this: Rust has the above "warnings" implemented, and their usage has enough fine grained control in order to allow the developer to tell the compiler "do what I say, I know what I'm doing".

IMO, Rust is the first contender that can displace C in systems programming (performance, the above safety guarantees, zero cost abstraction, no_std, unsafe, no garbage collection).

IMO, had llvm and Rust (or something like it that provide the above) existed 20-30 years ago, it would have already displaced C.

IMO, like Linus is quoted above, it's going to happen one day. Why not start using better tools today instead of waiting until later?

Cheers,

Wade

[RahulSundaram]

All other example you provided in my personal POV are satellite operations since C/C++ code(other languages) is doing the heavy lifting whereas Rust is just managing(and I'm sure is great at it) and I'm not implying that is bad or anything but for example Stratis could be written in Go/C/C++ and probably the performance won't suffer too much for the end user if at all because at the end of the day the C/C++ are doing the actual hard job(XFS, kernel, DBUS, etc. etc.).

No, there are actual new production projects where Rust is the core of how things work for millions of users and not some side project as you keep implying. You are free to do your own research but your understanding here is outdated by a few years atleast. Satellite projects are how languages initially gain adoption but over time greenfield opportunities are present where the language is not merely replacing but creating new functionality. This is exactly what happened with Rust (and Go etc)

[Almindor]

He could have no objections, on Rust, but it would still be a bad move..
The Linux Kernel is already a chameleon, of crazy stuff, do not encourage that behaviour further..

I think you need to take this more like an evolution. If the Linux kernel stays in C it will eventually be left behind and replaced by something implemented in a more safe language that can provide the same (or even better) performance but with more safety guaranteed.

I can appreciate the complexity problem tho and I think one language should be chosen as the "next C" for the kernel. If it's Rust all the better as I think it's a perfect fit (saying that from embedded dev perspective btw.)

[jrch2k8]

I think you need to take this more like an evolution. If the Linux kernel stays in C it will eventually be left behind and replaced by something implemented in a more safe language that can provide the same (or even better) performance but with more safety guaranteed.

I can appreciate the complexity problem tho and I think one language should be chosen as the "next C" for the kernel. If it's Rust all the better as I think it's a perfect fit (saying that from embedded dev perspective btw.)

Well, C/C++ have at least 10 years left if no more, so no worries there and no other major kernel have even considered this since that task alone could take a decade on its own but yeah i still have have many many reservations about Rust so i would not personally bother with it until sometime in the future since C++20 is going great for me and i hate the Rust syntax but have nothing against it either, so i'll recheck my opinion about it when is more mainstream and had some battle tests on it.

Also embedded dev (fist pump)

[Alliancemd]

Doubt it can happen.
Old farts usually don't like change, so they will probably offer a lot of resistance to this...

[goTouch]

Kernel is the last place to mess up with multiple languages. Get Rust work well with Gtk, Qt and replace unsafe C/C++ code there first then we could talk about kernel. Yes there are work being done but mostly is wrapper around Gkt Qt, still far from wide acceptance.

[insilications]

Kernel is the last place to mess up with multiple languages. Get Rust work well with Gtk, Qt and replace unsafe C/C++ code there first then we could talk about kernel. Yes there are work being done but mostly is wrapper around Gkt Qt, still far from wide acceptance.

This.

[inout]

Phoronix: Linux Developers May Discuss Allowing Rust Code Within The Kernel

A Google engineer is looking to discuss at this year's Linux Plumbers Conference the possibility of allowing in-tree Rust language support...

http://www.phoronix.com/scan.php?pag...bers-2020-Rust

LOL. looks like the fuschia gang shooed him away !

[oleid]

Kernel is the last place to mess up with multiple languages.

Depends. If you restrict the new language to satellite code like drivers introducing a new language is not very invasive. Also, it might make the kernel-internal driver API more stable.

Get Rust work well with Gtk, Qt and replace unsafe C/C++ code there first then we could talk about kernel.

Different projects by different people. Some people are qualified to work on kernel code, others on GUI toolkits.

Yes there are work being done but mostly is wrapper around Gkt Qt, still far from wide acceptance.

As far as I know, there are currently no plans to - say - rewrite GTK+. It might not make much sense, anyway, since there is shared state everywhere in existing GUI toolkits and that is - for good reason - unergonomic to work with in rust. E.g. one would need to use RefCells to do the borrow checking at runtime.

That being said, there are totally new toolkits in the works experimenting with idiomatic (as in: a different software architecture) ways for creating GUI toolkins in a thread-safe way. Just to name a few.

https://github.com/redox-os/orbtk

https://github.com/linebender/druid

https://github.com/hecrj/iced

I've already worked a little with druid and I find it quite nice. Granted, they are not battle tested, yet(*). But considering the battles I've already fought with Qt5 in the context of shared state and OpenGL rendering (doesn't crash in one Qt version, crashes in the other) I wonder what battle tested actually means.

(*) OrbTK is the GUI toolkit for Redox-OS and it would seem druid is used for a font editor called Runebender sponsored by Google Fonts.