[geijoenr]

I believe Rust will benefit from the reality check that kernel development represents.

Kernel development is hard, and bullshit doesn't go very far in that context. Success for Rust in that environment (with some changes along the way) will be a proof of value.

[hardwaregeek]

You have a valid point although I wouldn't frame it as adversarial as much as mutually beneficial. There will certainly be some bullshit eliminated from Rust, but I would not be surprised if there is a similar quantity eliminated from the kernel. Even in the most scrutinized C codebase in the world, there are likely memory usage bugs. If Rust can find and eliminate them, while also improving its capabilities, we all benefit.

[GolDDranks]

I think Rust is a good position in the sense that the language and community has a track record and culture of going and solving problems instead of sitting on them forever. I agree that many challenges of kernel development are going to end up strengthening and evolving Rust as a language.

[pjmlp]

Solving async traits, having a proper concurrency runtime story, reducing the reliance on third party crates to ease error handling does seem to take out forever.

[GolDDranks]

While I agree that these are problems (and, they are being addressed), none of these problems are ones that have to do with Rust in Kernel. The developers actually keep a wishlist of potential or unstable Rust/libstd/libcore/tooling features they'd consider helpful: https://github.com/Rust-for-Linux/linux/labels/prio%3A%20met...

[FridgeSeal]

> Solving async traits

Pretty sure async traits are coming soon (next couple of versions?) which is pretty speedy considering what I understand to be a semi-thorny problem.

> having a proper concurrency runtime story

Do you mean the language/stdlib shipping an async runtime?

> reducing the reliance on third party crates to ease error handling

I for one don't rely on 3rd party crates for error handling often? Anyhow is the most common one I use, but mostly out of habit and laziness, not actual hard requirement....

[the_duke]

> Pretty sure async traits are coming soon (next couple of versions?)

No. There are ideas for how to do it, but as far as I know they haven't been tested out yet.

It also relies on pretty large features that are not proposed for stabilization yet (GAT and existential types). When that is done and the implementation strategy is chosen there will also need to be a RFC cycle, a phase of ironing out bugs and finally stabilization.

It'll be ... quite ... a while... I can't see it happening this year.

[tialaramex]

GATs are apparently very close to stabilization, I think I've seen Rust 1.62 suggested as plausible. So that's a big step towards the likely design of async traits. But sure, async traits is not likely to be this year. Fortunately although for some reason async traits are on pjmlp's must-have list, they're nowhere close to the critical path for Linux, which again is written today in C.

[pjmlp]

I was replying to

"I think Rust is a good position in the sense that the language and community has a track record and culture of going and solving problems instead of sitting on them forever. I agree that many challenges of kernel development are going to end up strengthening and evolving Rust as a language."

So I picked some ongoing language examples where this isn't quite true.

[FridgeSeal]

Ah, my bad, thanks for the correction! I think I might have got that timeline confused with some other feature haha.

[mcronce]

I usually use `thiserror` for errors, but all that is is a shortcut macro for `impl Error` and `impl Display`

[jupp0r]

Async error handling has been a nightmare last time I tried a few months ago. Has that improved lately?

[lijogdfljk]

Pardon my ignorance, but what do you mean? Handling errors with the async runtime..?

If you just mean handling errors from funcs .. it's no different than non-async, no?

[jupp0r]

Yes, if all error types from various libraries are `Send` + `Sync` it's easy, if not, you are running into issues where you need to wrap them in reference counted containers because some of them aren't copyable either. Crates like failure, thiserror and anyhow didn't simplify this (although I really like their general approach to wrapping low level errors in high level errors with a breadcrumb trail to details).

[scns]

I like your input, as critical as it is. Rust is developed by a community/foundation in contrast to C# (Java+). Anders Heilsberg, a brilliant language designer/BDFE can ponder and decide, after careful consideration, top down. Consensus takes time.

[ragnese]

> Solving async traits, having a proper concurrency runtime story

Something something let the Java guy cast the first stone.

> reducing the reliance on third party crates to ease error handling does seem to take out forever.

I've written a ton of Rust and I've never used any of these third party error convenience libraries. As far as I'm concerned there is no issue in need of solving around error handling in Rust.

[pjmlp]

Now I am the Java guy, impressive.

The "please don't offend this language I have intertwined with my own identity with" attitude in modern times is so tragic.

I have always been, and will be, plenty of things, and if it makes you feel good to call me Java guy, when someone criticizes your beloved Rust, please do.

[ragnese]

Meh. You often reply prolifically in threads that mention Java, defend/praise it profusely, and also seem to be very knowledgeable about the language as well as the JVM. So it's not entirely an insult when I call you a "Java guy".

But you're over-reading into my defense of Rust. My point is that the specific things you criticized as taking a long time for Rust are not actually taking a long time. My point with poking Java, specifically, is that Java is going on 30 years old and doesn't yet have an analogous feature. Moreover, since we're talking about Kernel dev, do C or C++ have a standard async runtime? Considering that there's little-to-no prior art for doing the kind of async API Rust wants without active garbage collection, I'd assert that it's hard to criticize how long it's taking. Do you know how long it "should" take? If so, how?

[bobbylarrybobby]

The lack of context is a pain. For instance, trying to open a file that doesn't exist just gives the error "file not found" without telling you the path you tried to open.

[ragnese]

Fair enough. But that doesn't have to do with the error handling mechanism of Rust, nor would any of these error helper libraries fix that. It's just a criticism of the error type that's actually returned. A Java-style exception can be written that's just as lacking. No language that I'm aware of will automatically include function arguments in its errors/exceptions- it's up to the author of the error/exception type to include that info.

[kaba0]

You can just map the error to a tuple for example with the file name.

[noobermin]

It's ironic that the framing of some parts in the article is that the kernel mindset is arrogance and self-assuredness and that somehow isn't applied to the rust developers approaching an ecosystem that isn't familiar. It reminds me of tourists who visit another country and try to get locals to do things the way they are familiar with as if something is wrong with the locals and their way of life. I generally agree with gkh's response here. It avoids the arrogance in the other way ("why can't these kids roll their own leftpad") and presents a more valid concern, that of the kernel's actual constraints.

[lmkg]

The person who is leading this project and making it happen, Miguel Ojeda, is a long-term kernel developer. Whatever your experience might be of other RIIR evangelism, this project initiative is coming from an insider rather than an outsider.

[noobermin]

I didn't critique the idea of Rust in linux, I am critiquing the attitude of the rust fellow asking for support of importing generic crates into kernel code and thus adding dependencies (that is, the point of the article).

[samth]

The article is by Jonathan Corbet, who has been a kernel insider for a very very long time, and is generally a strong proponent of the way Linux does things as a project.

[oscargrouch]

Your example is quite funny and also represents how i would approach the matter of becoming a linux kernel developer.

Even if C is not my primary language of choice, i would definitely try adapt myself to the ecosystem and not the other way around.

You have all the knowledge of other peers, manual, books, all the libraries, the whole ecosystem.. this cant be replaced.

Also there's something else about C nowadays, is the lingua-franca, the latim (or english) of programming languages. We use it to expose api's to others in any other language that want to consume it as a library.

There's something about culture that people often forget in tech.. it's the real backbone of any project that it's on its own feet.. and when you want to enter in a community you will be better of if you learn and adapt yourself into this community culture instead of creating cultural clashes into the community and try to overtake it (be it hostile or not).

People should be aware that this effort will make it possible to create rust-based kernel drivers and that's it. the RIIR folks are delusional and hype fueled and its better if the sane Rust community get away from them or start to get them back into reality as i bet they are not willing to expend 10 or 15 years of their lives rewriting big and complex piece of software for a likely no return as people will tend to keep using the software the have more community and that are stronger.

It's a much better approach for Rust or any other programming language to become research darlings and eventually become the primary ecosystem of a research OS that went well and is the thing that will replace Linux. The language alone wont do it, it must be able to be a contender to UNIX and POSIX, and whatever language that is in such a system will probably be the one that will become the dominant one in such a ecosystem.

Also another good approach is to virtualize the Linux Api like gvisor does is userspace or the fuchsia OS(and even FreeBSD) does in the kernelspace. So that you can create your OS and kernel in the best way you can looking ahead, and have this Linux compat layer where applications dont even need to be aware they are not actually running in Linux.

[kaba0]

You are fighting an imaginary opponent. The one proposing it is a long-time kernel contributor.

[oscargrouch]

> You are fighting an imaginary opponent.

Yes, i'm sure there's an imaginary opponent downvoting my comment.

Also there's a lot into my comment, and people are not even noticing it in the whole context.

If there's no reason, why people get so upset? just move on if you are not being mentioned, as it will clearly be the case if i'm talking about "imaginary opponents"..

> The one proposing it is a long-time kernel contributor.

I'm not saying anything about people working on it specifically, if you read my comment, there's a clear separation between serious people and the hype crowd (which is not just RIIR, but now also cryptocurrency fellows, etc).. i can't say where the people working on this fits, i don't know them. Don't know from which part of my comment you took that conclusion.

There are quiet, clever, serious people doing the work, like Hoare, Matsakis and the people that are real enginners, i have all the respect for them (and im pretty sure Rust have tons of such a people). To be fair, all languages have all kinds of people but i don't know what happen to some of them that tend to attract a certain type of people more than others, like the feeling a got from Haskell community more often than others (but given the community was much smaller)..

For instance talking about culture, C succeeded exactly because it was a pragmatic language very simple and efficient like their founders to get things done. With this culture, things happened to be done around the language and we have the ecosystem we have today.. it's a great hacker spirit of more humble, hard-working, behind-the-cameras sort of people which i sincerely miss in the days of instagram, tick-tock and tech celebritism.

[GolDDranks]

Just a note, I am an avid long-time Rust user and contributor, but I have never met these "RIIR folks". They seem to exist only in anecdotes.

[oscargrouch]

it just took me to scroll down on this same thread to find one sample

> * 11 hours ago | parent | prev | next [–] > Rust will quickly replace C in the kernel, I have no doubt about it

I've have seen tons of such a comment in all sort of products when the matter is discussed around here and elsewhere (twitter, reddit, you name it)

If you want to really get serious about this, i can feed this comment sections with tons of evidence over the course of the years.

[biorach]

Anyone who believes that Rust will quickly replace C in the kernel clearly knows very little about Rust or the kernel, and definitely should not be taken as a spokesperson for either.

I suspect that this "RIIR" that you seem to believe is some kind of "movement" is just a random assortment of clueless people posting in random places.

[hitekker]

A ruling clique spreads quasi-religious beliefs that boil down to "we're the future!" to prospective followers. The ones who join up, are inspired and push ever intensified (yet even more honest) versions of those beliefs onto others "we must get rid the old thing". In one or two cycles of evolution, their evangelism provokes hostility from the unconverted. Unwilling to confront their own motivations, the rulers ignore how the spirit of their beliefs implicitly sanctioned their adherents misbehavior "technically, no one said they want to destroy the old thing".

A simple pattern that rulers to turn a blind eye to the connection between belief and action.

[GolDDranks]

Ugh yeah, now that you point it out, there was one. To be sure, my internal reaction to that comment was "oh, a troll or a loonie", but maybe they were serious, which is kinda worrying.

[throwaway82652]

>Kernel development is hard, and bullshit doesn't go very far in that context.

I don't know what it is about Linux that makes people say this. Kernel development has most of the same constraints as any other embedded context, which Rust has plenty of focus on. No it's not as mature as C, but few languages are.

Plus if you go looking in the kernel you can still find plenty of bullshit hacky code. It's not special, it's just another random open source software. The quality very much depends on the individual maintainer of that subsystem and how much has been invested in that area.

[npigrounet]

Rust will quickly replace C in the kernel, I have no doubt about it.

[ilovecaching]

I work on the kernel for a living, and I find this claim exceedingly dubious. We're currently talking about experimentally supporting modules written in Rust, which is an entirely different beast than replacing pieces of the kernel core. The barrier to entry for drivers is significantly lower, and driver quality can be much, much poorer than the quality of the core kernel. Many parts of the kernel have been fine tuned for decades, and many of the kernel developers that maintain Linux are also C experts (myself included) who aren't going to slow down development to migrate working code to Rust. It's great that we can experiment and see how Rust goes for driver authors, but they are still bus API consumers, not core kernel.

[tialaramex]

As I understand it the crucial rationale for drivers is that drivers were anyway necessarily platform dependent which undoes one argument against Rust.

Today Rust does not overlap Linux in terms of platform support. There are (small but very much alive) communities doing Linux on architectures that Rust has no support for and in some cases has no plans ever to support. So this makes drivers the only case where choosing Rust doesn't mean some people lose out, as a platform e.g. with no PCI bus doesn't get to run PCI drivers even if they were written in C.

I expect that over the next say, five to ten years, two things will happen to greatly improve this, maybe to the point where you absolutely could rewrite core Linux code in Rust if you wanted to. Firstly, Rust will get more platform support. Linux doesn't really need Rust's "Tier 1" (Linus doesn't check every kernel release passes tests on all real Linux target hardware as I understand it) but clearly you want Rust to at least build and take patches for every Linux platform some day. Secondly, some older platforms will "rust out". If your community is nursing 30+ year old hardware and increasingly more maintenance work is shared between fewer shoulders at some point "Linux-next" is not a priority and your platform will stop being supported while effort moves to exciting new hardware.

[sophacles]

There's active work being done on the rust gcc backend and it's progressing nicely. That should help with some of the platform concerns you (rightly) raised.

[rrdharan]

> Today Rust does not overlap Linux in terms of platform support.

Nit, I believe actually the Rust and Linux platform sets would be considered "overlapping sets" in the mathematical sense :), since neither is a subset of the other.

e.g. Rust platforms include things like the NetBSD Rump Kernel and Redox and I think one would be hard-pressed to claim that Linux supports those as platforms.

https://doc.xuwenliang.com/docs/rust/1423

[MYEUHD]

>I work on the kernel for a living

I'm interested in kernel development and I like the idea of working on it for a living. Can you give more details about your job? What does it consist in? Is it mostly code-review? Or are you responsible for maintaining a part of the kernel. Who is the entity that pays you, and what are the criteria they'd use to pay a new contributor to work on kernel full-time? Finally, can you point me to beginner-friendly things to work on to get started? how do I know which part of the kernel I should study and contribute to?

[nightfly]

If you define quickly as "over the next 10-20 years, maybe", then yes

[yjftsjthsd-h]

In fairness, that is... if not quick, then not slow either in kernel development time:)

[rob74]

Just as quickly as it replaced C/C++ in Firefox?

[zozbot234]

Firefox is getting new "oxidized" component all the time, Rust is the recommended language for both refactoring and new development. Of course the lowest-hanging fruits are addressed first, but that's normal and advisable.

[pjmlp]

Not after they let go everyone related to Rust, as far as I am aware.

Hence the crazy idea of now using WebAssembly in Firefox modules instead.

[tialaramex]

There's a big difference between "We don't employ the language's architects" (so far as I'm aware Mozilla also doesn't employ many WG21 members) and "We don't have any engineers who know this language". In 2022 you'd probably have to go out of your way to hire that many engineers and not get some people who know Rust.

Not to mention how much less experience you need in Rust to not blow everybody's feet off by mistake. I reckon if you have 10 years C++ and six months Rust, any Rust you write is already more likely to deliver reasonable performance without setting everything on fire than your C++. Because of the constant exposure to outright malevolent stinking garbage (in the form of other people's HTML, CSS and Javascript) the browser needs to be exceptionally robust, and C++ just isn't very good for that. So Rust is often a better fit for what Mozilla do.

[pjmlp]

Yet Chrome and Safari, the browsers that really matter in 2022, won't be moving away from C++.

Chrome folks have been playing with Rust, but seem more keen in improving their C++ static analysis tooling instead.

As for Mozilla, it is 10% of Rust code and lets see for how long Firefox still matters, given the existing 3% market, even EdgeChrome has surpassed it.

[steveklabnik]

That's not correct. Firefox continues to gain new Rust code. Compare https://web.archive.org/web/20201109025230/https://4e6.githu..., the first version of this page archive.org saved after the layoffs. 9.5% Rust, 2.9 million LOC. Today https://4e6.github.io/firefox-lang-stats/ 10.1% Rust, 3.4 million LOC.

[pjmlp]

10% in a browser currently having 3% market share with a decreasing tendency towards 0%.

Most of that code is surely related to what was replaced initially instead of new subsystems being ported.

[dralley]

Please don't spout nonsense. They did not let go of "everyone related to Rust", large parts of Firefox are written in Rust and those parts obviously need to be maintained. New Rust code continues to be written, as others have pointed out.

What Mozilla did do was lay off many of the people working on Rust itself as their full-time job, as opposed to people who use Rust to do their work at Mozilla. And the Servo team, unfortunately.

[pjmlp]

Hence why I mentioned "as far as I am aware" instead of stating is a fact.

The 10% as pointed out in a sibling comment, while admirable isn't large parts.

[devmunchies]

I'm new to programming, whats Firefox?

[kibwen]

Rust is great, but let's not get ahead of ourselves. :P

[matheusmoreira]

I have no doubt we'll be seeing Rust kernel modules but quickly replacing C? I don't think that's realistic.

[lostmsu]

I have a very strong doubt about it because Rust debugging still sucks. No debugger allows you to evaluate function calls AFAIK, which is a very strong restriction.

[toast0]

That doesn't seem like it would matter in the Linux kernel, since they don't have a kernel debugger, for better or worse.

[saagarjha]

Running GDB against the kernel running in QEMU?

[umanwizard]

I have definitely evaluated function calls in rust-gdb.

[lostmsu]

I see reports of it working for trivial top-level functions with basic parameter types, but what about everything else? Like member functions, trait implementations, etc.

[umanwizard]

You’re absolutely right that it often fails on more complicated stuff. I’m just pointing out that it’s not _totally_ nonexistent.

[Bancakes]

If by "replace" you mean "nobodies rewrite existing crap into Rust", then yes.

[LoveMortuus]

That's a bit harsh of an approach. And I think at least Doom would disagree.

[nomoreusernames]

he means in the context of a kernel developer. im sure there is some nerd who would rewrite stuff to prove to themselves and shutup their inner imposter syndrome. but mostly its quite accurate.

[mhaberl]

> rewrite stuff to .. shutup their inner imposter syndrome

you think that might do it?

[nomoreusernames]

ffs dont do it. no its not enough. you will always feel that feeling because you are born into this world and it absolutely makes no fucking sense. so you want to atleast feel competent in one thing. but you wont ever feel competent in life because this whole experience of existing is fucking ridiculous. bla bla computer bla bla ping pong. you are an ape and we are spinning around. imposter in the world. not in knowing a "job" skill. haha you comment is so deep i wanna give you a hug and buy you a beer.

[Bancakes]

Rust is evidently an impostor language.

[oxff]

The issue with Kernel development is that it's a dying profession. Nobody is interested in it. That's why there's an attempt with sexy new language, to bring more developers to work on it.

Probably less than 30 people in the world understand the thing as a holistic entity. From evolutionary terms, there's a giant risk of losing relevant technical knowledge to keep it up in the future.

I do not support adding it to the Kernel, I think we should just throw away the kernel entirely, but I understand why they're looking at Rust.

[biorach]

> The issue with Kernel development is that it's a dying profession. Nobody is interested in it.

That's a pretty wild assertion and files in the face of the highly active kernel development process.

e.g. > Linus has released 5.18-rc1 and closed the merge window for the 5.18 release... 13,207 non-merge changesets were merged during this merge window.

https://lwn.net/Articles/890119/

> I think we should just throw away the kernel entirely

That's the dumbest thing I've see on HN in some months. The kernel is deployed in hundreds of millions of devices worldwide and continues to be the dominant OS in many many sectors.

[oxff]

The issue is about the # of new developers joining the development if you look at the Linux kernel development as an organization, not about # of non-merge changesets merged.

[phendrenad2]

> That's a pretty wild assertion and files in the face of the highly active kernel development process

No, OP is right. 99.9% of things added to the kernel in any given release are drivers (mostly for obscure server hardware that the average LKML lurker would never have access to). So while there's certainly active development, it's all centered around drivers, and the "kernel" part of the kernel are mostly stable (modulo the occasional greenfield project like eBPF). (Note that I said 99.9% of things added, I'm sure security patches make up a lot more than 0.01% of kernel patches).

[staunch]

> The kernel is deployed in hundreds of millions of devices...

There are billions of Android phones alone. Not to mention the huge numbers of servers, IoT devices, embedded computers, and all the SBCs in my closet.

[samhw]

To be charitable, they may have meant something more like 'personal devices which people use directly'. (Though maybe not - it would be odd to exclude servers, which are one of Linux's biggest 'clients'. Perhaps they meant to exclude the more mundane types: routers, lightbulbs, etc.)

[pjmlp]

That Linux kernel is full of Google specifics, uses a microkernel like architecture since Project Treble, can be compiled since years with clang, now uses Rust for Bluetooth drivers,...

[staunch]

https://www.androidpolice.com/2021/09/24/google-plans-to-bri...

[pjmlp]

Marketing,

"The timeline for shifting to an "upstream first" cycle for new features starts in 2023, with 2020-2022 dedicated to making it work for pre-existing functionality. The Pixel 6 is expected to be the first Android device to ship with the GKI and Linux kernel 5.10, marking a major step in this process."

Means this is still one year away, if it actually happens, and then only Pixel devices will support it anyway, as so far most OEMs couldn't care less.

Not to mention that upstream will never accept all the things that make Android Linux not really Linux.

[jerf]

The kernel isn't dying, it's niche. It always has been and it always will be.

Fortunately for the kernel, despite being niche, it has a rock-solid onramp forcing people to get into it. There will always be companies interested in the n'th degree of performance, both generally, and for some specific hardware. Someone has to go do the relevant kernel work for those things. So while you or I may never touch it, it is effectively impossible for a kernel like Linux to just rot away because nobody cares. It would require first a multi-year, if not multi-decade process of fading first.

[biorach]

nice?

It's on most of the smartphones on the planet. Plus it is the dominant server OS. Plus in the top 3 in many embedded categories (a highly diverse set of technologies)

[jerf]

In context, it should be clear that kernel development is a niche.

[teddyh]

> It's on most of the smartphones on the planet.

Sadly enough, probably not for long: https://en.wikipedia.org/wiki/Fuchsia_(operating_system)

[samhw]

Haha, I heard another good one about a nun going into a bar..

[teddyh]

Even if Fuchsia is crapware, Google has the money to keep polishing that ball of mud, and eventually force it as the new version of Android, quality be damned. The rest of the world will have no recourse but to switch. It will be painful for quite a while, but people will survive. I mean, people survive using Windows, and not enough people switch away from that, either.

I’m not saying that Fuchsia is necessarily bad, I’m saying that Google will do anything to get away from GPL code, including, if necessary, forcing Android to Fuchsia. It doesn’t actually matter if Fuchsia is any good.

[camgunz]

I think you're talking about users and they're talking about engineers.

[pjmlp]

Android Linux !== Linux.

[capableweb]

> Probably less than 30 people in the world understand the thing as a holistic entity

As we only have two other "big" (popular) kernels to compare to this one, do you think they (Apple and Microsoft) have more people "holistically" understanding the entire kernel or less? Since the nature of those companies are closed-source, I'm fairly certain even less people understand those ones "holistically".

> I do not support adding it to the Kernel, I think we should just throw away the kernel entirely, but I understand why they're looking at Rust.

How would that work in reality? Re-use the existing tests to build a new kernel from scratch? Sounds like a very far-out idea that wouldn't help with any of the current problems, but I'm happy to entertain the idea and hear your reasoning here.

[yjftsjthsd-h]

> How would that work in reality? Re-use the existing tests to build a new kernel from scratch? Sounds like a very far-out idea that wouldn't help with any of the current problems, but I'm happy to entertain the idea and hear your reasoning here.

While I would tend to agree that a full production replacement would be such a massive undertaking as to be impractical, https://github.com/nuta/kerla does something very like that - Linux userspace ABI on an all-new Rust kernel. (And even at this small scale, I find it mind-blowing that this worked)

[ImprobableTruth]

Since they're complaining about maintainability, I assume they're advocating for microkernels?

[zozbot234]

AIUI, you can still build a minimal kernel that's easily understood as a whole. And patches to shrink the minimal build even further are highly sought after because they expand the usability of Linux in deeply embedded environments.

[sophacles]

Oh no. We have some early career devs that put up patches to the kernel recently. They were super excited about getting to do that work, and it was a big day for them - as it should be it's awesome.

I guess I need to go let them know they are Nobodies. oxff said so.

[LeFantome]

There may not be many “big and professional” operating system projects but, at the hobby level, it seems that there is a lot of interest in kernel dev actually.

HaikuOS, SerenityOS, Redox, and ReactOS are all going strong. The BSDs continue to advance as well. Redox is written in Rust even.

I believe Google sees Fuschia as a true Linux competitor.

When you say “we should just throw away the kernel entirely”, what are you suggesting?

[unmole]

> That's why there's an attempt with sexy new language, to bring more developers to work on it.

At no point did any active kernel developer express any such sentiment. Nobody is worried about not being unable to attract new blood.

[pohl]

It's only spoken of in knowing glances, like Voldemort.

[umanwizard]

> I do not support adding it to the Kernel, I think we should just throw away the kernel entirely

What would you use instead?

[matheusmoreira]

> The issue with Kernel development is that it's a dying profession. Nobody is interested in it.

That's simply false. I'd love to work on the kernel. I have immense respect for the people who work on it. Only reason I haven't tried contributing code is I don't think I'm skilled enough.

[phendrenad2]

> 30 people in the world understand the thing as a holistic entity

Probably a lot more than 30. There are probably more than 30 PhD students studying kernels at this very minute. However, I think you're right that no one is interested. People greatly underestimate the effect the kernel has on the full OS. They think it's "just" the kernel. This is why so many people keep saying that Windows will get a Linux kernel in Windows 10, no, 11, no, 12, etc. It's just a "kernel", like a grain of corn, something insignificant. So there isn't much interest in working on kernels. It's as unsexy as it gets.