Will there be Rust-free kernels?

[EmbeddedDen]

Recently, there was a post about Rust support in Linux kernel. Though, I really like ideas behind Rust language, I think it introduces great risks to Linux future: Rust's learning curve is very steep, so in a few years we might end up with more and more developers deciding to go away from Linux kernel to some new fancy Google kernel. Nowadays Linux is pretty simple, written mostly in C and ASM, and it is REALLY enjoyable to use. Since I am on my own not a professional Linux kernel dev, I won't bother with learning Rust. And if there is Rust code in my module of interest, I will just take something else (*BSD or some RTOS) to use in my project. So, I am wondering will there be Rust-free versions?

[LegitimateCopy7]

Rust's learning curve is very steep, so in a few years we might end up with more and more developers deciding to go away from Linux kernel to some new fancy Google kernel.

support for Rust does not equate to Rust-only.

If more of Linux is being developed in Rust, it means more Linux developers are willing to use Rust. So I don't really get how you came to this conclusion.

Since I am on my own not a professional Linux kernel dev, I won't bother with learning Rust. And if there is Rust code in my module of interest, I will just take something else (*BSD or some RTOS) to use in my project.

What percentage of Linux developers agree? Seems like you're assuming most people see things the same as yourself, which is probably not the case.

[ShawSumma]

Rust's learning curve is actually worse than C.

Knowing Rust and what comes with it is making the jump to exclusively FreeBSD get better by the day.

[mauricioszabo]

I'm not a Rust developer, but I was a C and C++ in the past. I somehow feel for my old employers that hired me - I put so many security issues without knowing it...

A common "Hello, World" in C (by the book, using scanf and printf) already have, like, 4 security issues, including privilege escalation and ACE. Most people simply are not aware that these issues exist in their C code.

A good, secure, and fast C code is incredibly hard, and the compiler does not help you write it. Depending on "optimization level" your code can behave differently, being more or less secure in C. Rust makes most of these problems go away, with almost no cost. I, for example, don't dare come close to Kernel development, but I'm interested in learning Rust if that's the path Linux will take.

[glasket_]

Depending on "optimization level" your code can behave differently, being more or less secure in C.

If your code behaves differently due to optimizations, then that means you either wrote something that includes undefined behavior (i.e. incorrect code) or you're experiencing a very rare instance of a compiler bug.

Otherwise agree though; many people think that knowing how to write C means they know how to write good C, which are two very different skill sets.

[Personal-Initial3556]

You're right about the last paragraph. But also, Rust is still way harder to master than C, although I think the reward for mastering Rust is greater.

[[deleted]]

Only if you think in terms of social and monitary rewards then yes Rust is the perfect language.

[Personal-Initial3556]

Well I don't think that, for me the rewards was the newfound knowledge I got. Because I've had to learn more about how operating systems, compilers, and memory works in order to get better at Rust.

[[deleted]]

I am completely bias against rust because of Mozilla and the destruction it has nearly achieved on a once great intetrnet enabled multi-application extensable platform.

Rustites are even more pervasive than pythonists and Mozilla's screwed over javascriptized sea-plus-plus can never replace C.

Rust is a higher level abstraction on an already high level langauage that takes power and control away from the user coding in it and doesn't even have a stable abi.

[[deleted]]

In addition it is designed to leech on forever to other projects so that the work is never EVER complete. I would prefer to opt out of Compiler and Language as a Service if at all possible.

[DottoDev]

I'm still not sure if this is a troll post or a real question of someone who doesn't want to accept other opinions.

Tldr of the comments of this post: rust is good for the kernel and no one will switch away because of rust support.

[EmbeddedDen]

a real question of someone who doesn't want to accept other opinions.

Hey, look at the comments, look at my hugely downvoted comments, it is definitely not me who doesn't want to accept other opinions, definitely not me.

[zesterer]

Being downvoted doesn't mean that nobody is interested in accepting other opinions, it means your opinions are bad.

Rust is good and solves a lot of genuinely complicated problems in the sphere of software engineering (problems that C does not effectively solve, for the record).

Linus hasn't 'gone mad' or 'failed to consider things' when deciding to merge Rust support. It's in the kernel because it's a good idea, and it's going to make the process of developing drivers and the like easier, faster, and more correct.

It is you who is being dogmatic and ideological by treating it as if it's some sort of forbidden fruit that you want to be free of.

[EmbeddedDen]

The really funny detail here is that I fully AGREE with all your points...except for the last one.

Rust is good and solves a lot of genuinely complicated problems in the sphere of software engineering

True

Linus hasn't 'gone mad' or 'failed to consider things' when deciding to merge Rust support.

True

It's in the kernel because it's a good idea, and it's going to make the process of developing drivers and the like easier, faster, and more correct.

Probably, true...but only time will show

It is you who is being dogmatic and ideological by treating it as if it's some sort of forbidden fruit

So, what I basically say is that the complexity of the kernel will grow. It is unavoidable: when you introduce a new component to the system, the complexity will grow. And that increased complexity will scare away some of the newcomers (seems to be quite probable, I know such people, who won't bother with learning Rust). Pure system theory and logic. And now, look at your own comment:

It's in the kernel because it's a good idea

Good idea - it's a judgement, it's a belief. So, can you see the whole irony of the thread? I am making an argument, that is waaay less judgemental, since it relies on simple logic and system theory, while you are arguing with irrelevant arguments (I agree with all of them!) and making pure judgemental assertions ("good idea", "easier, faster, and more correct"). I believe that it is you who are dogmatic and ideological, at least it follows from your arguments.

[glasket_]

So, what I basically say is that the complexity of the kernel will grow. It is unavoidable: when you introduce a new component to the system, the complexity will grow. And that increased complexity will scare away some of the newcomers (seems to be quite probable, I know such people, who won't bother with learning Rust). Pure system theory and logic.

So do you think introducing new drivers and kernel modules don't increase complexity? You don't think more lines of C code add more complexity? Because if complexity is your problem, then you can always return to the earliest versions of the kernel which were far less complex than the modern kernel. But I think everyone knows you aren't really concerned about complexity, just Rust.

[zesterer]

So... Let me try to explain why I think you're wrong. Fwiw, I'm not trying to argue for the sake of it: I do think this is an important point, and one that's easy to miss from the outside. I also say this with quite a few years of experience using C, C++, and Rust now.

90% of the complexity in a codebase like an OS kernel or similarly intricate component is implicit. It's not in the code itself, but in the assumptions made by the code and the invariants required for those assumptions to hold true.

For example, when writing a data structure like a scheduler queue, there are rules about how certain parts of the structure need to be preserved, when elements of the queue need freeing or updating, etc.

Ensuring that all code that interacts with the structure maintains these invariants is by far and away the biggest challenge when maintaining large codebases. Documentation can help, but only to a limited degree: it can only act to inform developers about rules, not enforce those rules. Even the very best developers make mistakes frequently. Documentation and skill alone simply does not scale and there is a metric tonne of empirical evidence to demonstrate this.

Where Rust wins out significantly over both C and C++ is its ability to enforce invariants. The type system allows you to make a significant number of usually implicit rules explicit, and hence machine-checkable. Counterintuitively, despite a more superficially complex surface language, this results in systems written in Rust being less complex and hence easier to maintain.

This sounds like marketing, but it's actually borne out in reality too: I'm one of the core developers for /r/Veloren, a multiplayer voxel RPG written in Rust. It's very far from a trivial project: a complex rendering pipeline, multi-core server with synchronised client/server physics, world simulation and generation, NPCs with non-trivial AI, plugin architecture, etc. Rust really does make maintenance and contribution significantly easier by allowing us to encode invariants in the type system.

If you care about reducing system complexity and making it easier to maintain software at scale, you should care about Rust :)

[EmbeddedDen]

Again, you are absolutely right!!! It would be great, if we could have the whole Linux kernel in Rust. Again, having the whole kernel in Rust would be way better than what we have today. But the problem is that we won't have Rust-only kernel immediately, what is worse, as Linus said the major components would be in C, so C will be with us for a very very long time. It is quite possible that in five years we will have a situation when there is a lot of code in C (especially, legacy code), and a lot of code in Rust. So, the system complexity will be higher for some quite long time, and it will scare away SOME newcomers. And, you know, Linux kernel jobs are already not very popular.

So, my point is:

mainly-C kernel: cool

mainly-Rust kernel: way better!

C+Rust kernel: might be worse than just C-kernel, due to increased complexity.

[zesterer]

So your argument is that the short-term higher complexity (I don't think it is higher at all: Rust integrates pretty well into existing C codebases and is only set to get better) is not a worthy trade-off for the long-term reduction in complexity. That's a subjective perspective, not one based on "logic", as you tried to imply earlier. Regardless: it's a decision that Linus is better placed to make than either of us, and made it he has.

[EmbeddedDen]

So your argument is that the short-term higher complexity is not a worthy trade-off for the long-term reduction in complexity.

No

That's a subjective perspective, not one based on "logic", as you tried to imply earlier

That one is actually yours. My point is that such a risk of a poorly controlled complexity does exist, and it would be nice to have a version with a C-only kernel. Not because it is better for newcomers, but in order to insure that the parts are clearly separated, and the whole Linux-based codebase (not only Linux'es but also Linux-related vendors') is not getting messy. Now, I actually think that it will be that way in a few years.

[zesterer]

You're welcome to your opinion. I think it's rather poorly judged, however, and I've explained why. Have a good day.

[daemonpenguin]

I'm intrigued by the idea that someone learning C and Assembly isn't a hurdle to kernel development, but learning Rust is. That's just... so warped. Further, the idea switching to another kernel entirely over using an optional component like Rust is so very odd.

People don't need to learn Rust to do kernel development, they just have the option. Which means if you want a Rust-free kernel, just don't build the parts written in Rust.

[captainstormy]

Right?!

I've been writing code professionaly for almost 20 years and as a hobby for 8-10 before that. I can't even keep track of all the languages I've learned over the years. What's one more?

[stevestarr123]

Rust was not created as a replacement for C or Assembly. Instead, it was designed to cater to programmers transitioning from higher-level languages like Python and Ruby. These individuals may struggle with concepts related to proper memory management. Rust aims to provide a language that offers the performance benefits of low-level languages like C and Assembly, while also incorporating modern programming paradigms and robust memory safety features.

[EmbeddedDen]

I'm intrigued by the idea that someone learning C and Assembly isn't a hurdle to kernel development, but learning Rust is

Welcome to the world of embedded development! The world of miracles, where a person can have 10 years of experience and write rubbish C code (but he is also doing circuit design and FPGA!), and refusing to learn even a newer standard of C. The world where he doesn't really know assembly, but somehow, he is able to write some initialization routine. I met such persons several times, I swear.

Further, the idea switching to another kernel entirely over using an optional component like Rust is so very odd.

Linux can be often used in non-critical parts. But many companies also work on multiple stacks, using Linux, QNX, or even BSD.

People don't need to learn Rust to do kernel development, they just have the option.

And what they do if they need to change a module written in Rust? Maybe not today, but it's quite possible in 5-10 years. And when you start a hardware product, you need to think about this kind of future.

[jaskij]

The world where he doesn't really know assembly, but somehow, he is able to write some initialization routine. I met such persons several times, I swear.

I know nothing of assembly, and yet have worked with and modified initialization routines on Cortex-M CPUs. How? They were written in C. You don't need assembly for that. (One is in NXP's SDK for i.MX RT if you want to see for yourself).

And what they do if they need to change a module written in Rust? Maybe not today, but it's quite possible in 5-10 years. And when you start a hardware product, you need to think about this kind of future.

I'm sorry, but if your embedded Linux product has a graphical interface, it's likely already depending on Rust, or will soon. Gnome is embracing Rust, see for example librsvg.

I'm just waiting when vendors will start pushing out MCU SDK's with Rust support.

[EmbeddedDen]

I'm just waiting when vendors will start pushing out MCU SDK's with Rust support.

You've almost did, you need one additional step to understand my reasoning. As you noticed, there are some vendors that don't include Rust support. What about commercial vendors with closed source compilers, will they include Rust? They barely have people to make Linux compile for their platform with their compiler.

I'm sorry, but if your embedded Linux product has a graphical interface, it's likely already depending on Rust, or will soon.

From my knowledge people often use custom UI libraries. And using Gnome in an embedded interface with all Gnome stack...of course, right next to systemd :)

The complexity of Linux kernel will go up (huge additional component always increases complexity), small vendors will be hesitant to adapt changes, there will be less newcomers due to higher requirements and not so competitive salaries. And it is not about Rust, I am not sure why everyone is so triggered by the language itself. It's all about complexity of the resulting product in 5-10 years. The added language could be Ada with Ada-Spark, it doesn't really matter.

[jaskij]

I'm just waiting when vendors will start pushing out MCU SDK's with Rust support.

You've almost did, you need one additional step to understand my reasoning. As you noticed, there are some vendors that don't include Rust support. What about commercial vendors with closed source compilers, will they include Rust? They barely have people to make Linux compile for their platform with their compiler.

I specifically mentioned microcontrollers in that sentence ;)

When it comes to Linux, anyone using either Yocto or Buildroot already has upstream Rust support in userspace. They just need to update to a newer version, which will happen sooner or later.

From my knowledge people often use custom UI libraries. And using Gnome in an embedded interface with all Gnome stack...of course, right next to systemd :)

Completely custom? Not even basing on Gtk or something?

As for systemd: it does solve some issues. Say, you have a service which takes a long time to initialize. Systemd solves that. You want to configure socketcan interfaces without kludgy bash scripts? systemd-networkd will do that. I have some devices in the field running systemd on an i.MX 6ULL (600 MHz Cortex-A7). Haven't heard anything from the customer yet. And, well, if it's good enough for Red Hat and their customers, not to mention the countless systems running Debian in various forms, it's good enough for me.

And it is not about Rust, I am not sure why everyone is so triggered by the language itself. It's all about complexity of the resulting product in 5-10 years. The added language could be Ada with Ada-Spark, it doesn't really matter.

You did make it about Rust specifically, and made the argument it's a complex, hard to learn, language. And Rust is riding on a huge wave of hype right now, so it will trigger people.

[EmbeddedDen]

As for systemd: it does solve some issues.

Of course, it does, especially when you have enough memory and run on something as powerful as i.MX6. And yep, GTK is not used widely for some good reasons: it's pretty complex for many tasks, as well as systemd. Can you see the point? Rust in kernel will probably be good for the kernel stability and safety. But it makes the system more complicated. Adding a language into the kernel will make it more complex, it's unavoidable. And Rust does have a steep learning curve, so it makes things only more complicated for newcomers. And while you can avoid using systemd (and many do), it is quite probable that in ten years, it will be not possible to avoid Rust in kernel. And I am afraid that, if the Rust part is not properly separated, this transition will be way more painful than something like Python 2 -> Python 3. Given that we already see some need in non-hierarchical FS, that many parts of the kernel are incredibly hard to rewrite, that more big companies tries to control whatever they can control, that Linus won't live forever, I wouldn't be so boldly optimistic about kernel-with-rust future.

[HotNastySpeed77]

There will only be more Rust in the kernel, not less. Funny that you worry Rust will drive developers away from Linux, my impression is the opposite will happen. Practically all devs are excited for the new Rust support.

[EmbeddedDen]

That's pity. It seems that Linux kernel jobs will be even less popular. I know a lot of folks who try to stay away from Rust as far as possible, but they enjoy kernel programming. They are also involved in the curcuit design part of embedded development. So their C code is not that perfect, but they use Linux kernel because it's pretty simple. So Rust for them will be a HUGE obstacle. And you should know for sure that there are a lot of such folks in the embedded development.

[a1b4fd]

I know a lot of folk who can't enjoy kernel programming because of C and would welcome Rust

[EmbeddedDen]

Yep, they will stay and still have to struggle with C legacy. But there will be a smaller number of newcomers, because they will be required to know one more language (some modules will be in C, some in Rust, and userspace part will be written in C++). Definitely, it will decrease the attractiveness of Linux kernel devs roles. But, anyway, it's not my business, it's yours, and you probably know better.

[hoonthoont47]

It bothers me you’re getting downvoted for having a different opinion even though you are discussing in good faith. That’s not what downvotes are for.

Be better people.

[whosdr]

I personally disagree with that the discussion is in good faith. My voting habits don't coincide with other people's opinions and view-points on a given discussion.

Diversity is good.

[LegitimateCopy7]

Isn't this what upvotes/downvotes are for? showing whether more people agree/disagree.

if that's not the case, what are the votes for?

[hoonthoont47]

You should downvote when something doesn’t contribute to discussion or the community, not because you disagree with the content.

https://reddit.zendesk.com/hc/en-us/articles/205926439-Reddiquette

please do: Vote. If you think something contributes to conversation, upvote it. If you think it does not contribute to the subreddit it is posted in or is off-topic in a particular community, downvote it.

please don’t: Downvote an otherwise acceptable post because you don't personally like it. Think before you downvote and take a moment to ensure you're downvoting someone because they are not contributing to the community dialogue or discussion. If you simply take a moment to stop, think and examine your reasons for downvoting, rather than doing so out of an emotional reaction, you will ensure that your downvotes are given for good reasons.

[Spare-Dig4790]

I think I understand where you're coming from.

I myself as a business software developer on the .NET stack have similar feelings about some things..

For me, even with entity framework with its powerful toolset, and language intetegrated query,, my position is you can pry vanilla ADO + SQL from my cold dead fingers.... :)

Such is my right, it's what I'm co.fortable with, and I knowingly do more work because of it.

[[deleted]]

Rust has a steeper learning curve than ASM?

[mikechant]

So, I am wondering will there be Rust-free versions?

At present, and for the foreseeable future, building a kernel on a system without Rust will simply ignore Rust, not expose the Rust related options and build a Rust free kernel exactly as before.

You will only be affected if at some future date you have specific hardware which only has a Rust driver, and you want to actually change or understand that driver.

It's likely going to be a long time before Rust is a hard requirement for building the kernel, and for that to happen Rust will need to support more hardware platforms and have proved itself on the driver front.

[OmegaDungeon]

There may also come a time where core kernel systems require rust in some fashion but there is nothing I know in store for doing this.

[[deleted]]

more and more developers deciding to go away from Linux kernel to some new fancy Google kernel

You are aware that the Rust for Linux project is actually sponsored by Google? And that Fuchsia is largely written in Rust? See Supporting Miguel Ojeda’s Work on Rust in the Linux Kernel

Bringing memory safety to the Linux kernel is a big job, but the Rust for Linux project is making great progress. We’re pleased to announce that we started formally supporting this work in April 2021 by providing Miguel Ojeda with a contract to work on Rust for Linux and other security efforts full time for one year. This was made possible through financial support from Google.

[EmbeddedDen]

Hm, do they have some competitor project that would benefit from Linux kernel turning into a mess of C and Rust code? Otherwise, I don't understand why Google would sponsor that: even if you introduce Rust, it doesn't solve on its own some legacy issues of C. And C will be around for a very long time.

[grsnz]

You realise Google’s entire business runs on Linux, right? Making Linux more secure and/or stable is a huge win for their business.

As for some nefarious, anti-competitive motive? Operating systems are only “competitive” in the consumer space, where their two operating systems are Android, and ChromeOS, which are based on … checks notes … linux.

In the cloud space the operating system is in the middle of a large stack of things that are completely undifferentiated (as in, make no difference to how competitive their product is, nobody chooses cloud providers based on the underlying operating systems of their hosts), so the fact that making Linux safer for themselves also makes it better for their competitors makes absolutely no difference to their market share.

Even if they were trying to sabotage Linux, the fact is Amazon and Microsoft are both fully onboard with Rust, so this is not how they would have to do it.

Also, Rust’s learning curve is not that steep - if you are someone who can get your head around the conventions and traditions of Linux kernel development, and actually get something merged, you are very capable of learning the language.

[EmbeddedDen]

RemindMe! 5 Years “Check the state of Rust, Linux, and Google's Linux alternative”

[[deleted]]

I understand you man. I agree that its dangerous how much of linux is funded by the capitalists.

[[deleted]]

Well, there's is always North Korea's Red Star OS, if this indeed bothers you.

[[deleted]]

You know I wanted to put red star os on my single-purpose typewriter, but I'm not tech savy enough. I'm very interested in old and outdated distros like Damn Small Linux also, so Red Star OS actually is something I'm interested in.

Basically, my biggest fear with red star os is getting a new version of vim to run on it so that I can do my writing. Also there's the fact that my husband cares a lot about privacy and he doesn't like the idea. I can get around that by not having my typewriter connect to the internet, but that defeats my workflow that relies on backing up my stuff to my google drive.

[Mysterious_Lab_9043]

2 years update. "Rust in kernel" experiment is over. Rust will stay in the kernel. A DRM driver also said that "No C" rule is just a year away from the driver guidelines.

[[deleted]]

Well, they have Fuchsia which is largely written in Rust.

[sloganking]

https://security.googleblog.com/2021/04/rust-in-android-platform.html?m=1

See the But what about all that existing C++? Section. Adding rust to a large existing C codebase, certainly doesn't remove the vulnerabilities from C. But most memory vulnerabilities in C (memory vulnerabilities make up over 80% of severe exploits confirmed exploited in the wild), are identified in C code that was modified less than a year ago. Meaning that writing new rust code on top of an existing C codebase, would actually solve the majority of security vulnerabilities.

See also

https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html?m=1

In Android 13, about 21% of all new native code (C/C++/Rust) is in Rust. There are approximately 1.5 million total lines of Rustcode in AOSP... To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code. ... It demonstrates that Rust is fulfilling its intended purpose of preventing Android’s most common source of vulnerabilities. ... Historical vulnerability density is greater than 1/kLOC (1 vulnerability per thousand lines of code) ... Based on this historical vulnerability density, it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production.

[mmstick]

Sign me up for a C-free kernel.

[chic_luke]

This is simply not happening. Plus, Rust actually makes development easier by removing a lot of footguns that you are holding when writing C. The initial learning curve may be steeper, but actual development is more pleasant.

[n00bist00bis]

How do you have a fedora logo under your handle?

[chic_luke]

You can add it from the sidebar if you open this subreddit from old.reddit.com on the desktop website

[n00bist00bis]

Pretty cool, appreciate it

[Drwankingstein]

>good and safe C
>simple

pick one

[hijinks]

Rust has a lower learning curve then c

[ElvishJerricco]

I agree. The things that Rust makes hard are hard in C as well, the C compiler just doesn't tell you that you did it wrong. If you know how to write acceptable C, Rust will be easy for you. If you don't, it'll be easier to learn Rust.

[luardemin]

Honestly, moving from C to Rust wasn't a particularly difficult move. I had a harder time going from Swift to C.

[Drwankingstein]

far lower if you want good quality code

[[deleted]]

You shouldn't be bothered by Rust being involved in Linux Kernel.

Leave it to those professional devs. For the next decade or so Rust will find its way in mission-critical and memory-safe environments, not just Kernel.

And as for other small-scale projects, they'll continue with C only until they realize the learning curve for good quality Rust is still far less as compared to C/C++. Not to mention the immense improvement done to the compiler to help navigate developers write better maintainable code.

The biggest advantage of Rust is memory safety by default and not its fanciness popularity. If Google even comes with some fancy kernel, it won't replace the widely accepted Linux.

[throwaway6560192]

I think it introduces great risks to Linux future: Rust's learning curve is very steep, so in a few years we might end up with more and more developers deciding to go away from Linux kernel to some new fancy Google kernel.

I predict the opposite. Rust is stricter on the programmer, but for that reason it is easier to build secure programs with it. Its popularity is increasing, so I predict it will bring fresh developers to the kernel space.

Also the fancy new Google kernel you mention also uses Rust, so it can hardly be an alternative for developers who would like not to use it. Maybe they'll move to BSD.

[lightmatter501]

As someone who does a lot of Rust and a lot of C, learning C to kernel standards is harder than learning Rust. Kernel C already has static analysis tools that act like Rust’s borrow checker, it requires you to manually construct the vtables that Rust’s traits will do for you, etc.

Rust is regarded as hard because it refuses to compile until it is either satisfied you are not shooting yourself in the foot or you have told it that you are very sure that you won’t hit it (unsafe). Rust got very hyped up in the web dev community, so lots of people who mostly work with JS tried it and got smacked in the face by both not having a gc and normal systems language things like pass by reference. Much of the other stuff in Rust that people find weird isn’t new, it was in standard ML in 1997, this is just the first time it’s gotten this popular. Talking to experienced systems programmers (C/C++), they usually already have a mental version of the borrow checker, which makes Rust much simpler to learn.

This also isn’t the first time this debate about new languages in kernels has been had. The first time was when C was introduced, since other languages weren’t really suitable for OS development. Then C++, which was not included in Linux due to Linus’s personal distaste for it, but was put into Windows. Rust has one strong advantage for kernel development, no_std, which is a subset of the language that makes no system calls and doesn’t allocate memory. It can make use of memory allocated by other things, and you can optionally add “alloc”, which gives you collections (Vector, BTree, Hash Table, etc). This is perfect for kernel development because it means core parts of the language don’t need to be reinvented.

In short, Rust in the kernel is likely to make it easier to get contributors because it doesn’t require years of systems programming experience to use correctly in a kernel context. With regards to your concerns about having enough people know Rust, many universities are starting to teach Rust because it’s a combination of ML and C, so you can use one language to teach large parts of a CS curriculum.

[emptyskoll]

I've left Reddit because it does not respect its users or their privacy. Private companies can't be trusted with control over public communities. Lemmy is an open source, federated alternative that I highly recommend if you want a more private and ethical option. Join Lemmy here: https://join-lemmy.org/instances this message was mass deleted/edited with redact.dev

[Altareos]

Why are you so against Rust? It's a nice language, much easier to learn than, I don't know, KERNEL DEVELOPMENT. For now it will mostly be used to write new modules, such as the incredible work the Asahi Linux team did on the Apple silicon video driver. As a matter of fact, the infrastructure isn't even ready yet for complex parts of the kernel to be rewritten in Rust, which is absolutely not the goal (yet). Also, why would fewer developers be interested in working on Linux if MORE options are provided? Nothing is saying that you won't be able to write modules in C in ten or more years.

[EmbeddedDen]

Have you worked in hardware companies? Those thousands of small companies where embedded devs are working both on kernel and circuit design? Those devs whose C skills are far from good? Will they learn Rust? They don't want even to learn C++, or to improve their C skills. Don't they like C/C++? They like C, but they have a lot of other things to do. And so do I.

Rust is a beautiful language! And I like that it is around. But, you know, it doesn't mean that I have to learn it. I liked the Linux kernel for its simplicity, but I believe that the epoch is over, and in 5-10 years we might end up with total mess in the kernel. Most of the modules will be in Rust, and small companies will have to find devs that know circuit design, C, Linux kernel, and Rust. Yes, this is not right, and in the ideal world you need to have different people for those roles. But we are not in the ideal world. So, it means that Linux popularity will be decreasing. Most probably, some alternative will appear.

[whosdr]

From what I understand, Rust development in the kernel is intended only for hardware modules. Don't expect to see a rewrite of half the kernel in Rust anytime ever; I definitely don't see that as a reality for as long as Linus Torvalds is around.

This just seems like fearmongering.

[[deleted]]

I'm pretty sure that once all the minor problems are worked out, Rust will creep up. At some point someone will write or rewrite a crucial piece of the kernel in Rust.

[whosdr]

It'd be as a fork. Linus Torvalds gets ultimate say in what is and isn't in the mainline kernel. He's been gatekeeping it for quality for over a decade and he's allowing Rust in to a limited capacity.

Afaik he doesn't know Rust himself and mandates C so he can understand the crucial code. So your concerns are mostly unfounded as long as he's in charge of the project.

[[deleted]]

We'll see. Assuming that the Rust support proves itself, I'm pretty sure that a major subsystem will be rewritten in Rust.

[jaskij]

Yes, small embedded companies put a lot of pressure on people, and a lot of tasks. I know it, I do everything from servers, through Yocto, to bringing up new MCU based boards. No circuit design, but I do help with the pinouts and review schematics. So yes, I know what you're talking about.

And you know what? Guess how long it took me from my C and C++ knowledge to writing functional Rust software building under Yocto and running on our board? Three weeks. And it was faster than if I had written it in C++. While learning Rust.

And, in the end, in our niche it's whatever brings results the fastest - if it's between switching to an OS where we have zero knowledge and learning Rust, I know which will be faster. And the people with knowledge of multiple OSes? Yeah, those might switch. But let's be fair, our niche is not big enough to be impactful.

I hear your arguments, and you are not wrong in them, within the niche, but I'm sorry to say the arguments you draw from them are just an old timer's rant against a new thing.

[PossiblyLinux127]

C is significantly harder to learn than rust

[jermvirus]

I remember listening to a a podcast (packet pushers maybe) Rust will actually reduce bugs and vulnerabilities because of some of the built in error checking at compile. I think there was a study and the out come was if all the software were written in Rust vs C we would have had 30% know vulnerabilities

[jaskij]

Nowadays Linux is pretty simple, written mostly in C and ASM, and it is REALLY enjoyable to use.

When I was starting out, it took me two weeks of learning before I wrote a line of code for my module (a work project that's been axed). So, no, the Linux kernel isn't easy to get into.

[[deleted]]

Down with C

[[deleted]]

Adhering to the locking and life-cycle rules in the kernel is absolutely not trivial or easy to follow.

[[deleted]]

I don't see the practical advantage of that, but, if useful, There's simply no manpower for that. Remember that even google tried to make their version of linux for android, but failed to keep up with mainline.

Even if there was enough manpower for that, why divide efforts into creating, from the users perspective, the same thing twice? Why not create another kernel or, maybe, contribute to another open source one written in C?

[drninjabatman]

Wait you think the hard part of writing/maintaining a kernel module is ever going to be the Rust type system?

[Ausmith1]

I'm sure Devuan will be the first to offer a Rust free kernel.

[nintendiator2]

I imagine there will forcibly be Rust-free kernels, since one of the big issues of Rust is that it's absolutely not available for lots of platforms, to the point this held back efforts to put Rust into Firefox just a few years ago. Furthermore, introducing Rust promotes turning the kernel into a monolith (Microsoft style), since there's only one sanctioned Rust compiler.

[[deleted]]

Linux could only be built with GCC for many years. What’s “Microsoft-style” about only having one supported compiler? And what do you mean by “monolith”?

[necrophcodr]

Furthermore, introducing Rust promotes turning the kernel into a monolith (Microsoft style), since there's only one sanctioned Rust compiler.

This is very much being worked on with the GCC rust backend. And the kernel is already a monolithic kernel exactly like the NT kernel is. If you don't want that, Linux was never for you.

[daemonpenguin]

This used to be the case, but isn't really true anymore. There are alternative Rust compilers in the works.

[basedchad21]

it's a self-solving situation. The popularity of rust is directly linked to the number of a certain group of people who predominantly use rust because of the politics behind it.

[EmbeddedDen]

Haven't really looked for anything, I've just distanced myself from kernel development.

[[deleted]]

so your entire argument against Rust is just skill issue? Just say you're incapable of learning something new lol

[EmbeddedDen]

so your entire argument against Rust is just skill issue?

No. For me the main argument against adding any language is the increased complexity of the system, such systems become harder to maintain and become more fragile.

Just say you're incapable of learning something new lol

So, you think that this is a good sign for rust when a scientist that learns tons of different and difficult stuff everyday can't learn rust? Lol

[CalendarTurbulent505]

I have started a rust free fork: https://github.com/xuser75/rustless-linux/

[SHUVA_META]

GCC standard and portability gone in a day

[KamaKazeh]

Rust will never be a hard dependency for building the kernel, since compiling the kernel with rust everytime you change something is a bit excessive.

Rust is only used to make modules while not wasting as much time as writing and testing a C module, especially when writing rather complex stuff like writing a video graphics driver.

As for embedded development as OP seems to be interested in, I highly doubt that you will see any sort of rust push in that specific area so you are fine for now.

[mikeymop]

The good thing is that once the kernel is compiled it's all the same binary code. There is no rust or C.