You're asking for enterprise-grade, production ready kernels, and immediately after say Rust is nearing maturity. There you go.

Writing a kernel is like building a cathedral. To have a production ready kernel, set aside 15 years, or the equivalent in dollars, at least a couple billion. This is why stuff like Serenity, which is an outstanding achievement, is not much more than a toy.

We will have a Rust based kernel that is memory safe. Not this decade though. By that time Linux will have replaced more and more subsystem with Rust already. Remember, enterprise grade means boring and stable. It is nonsense to want a new, unproved kernel to provide that level of safety out of a language that has reached 1.0 not very long ago.

Personally, I think Linux is plenty good enough, but we have seen the best UNIX can offer. It's time to move on and try something new.

> By that time Linux will have replaced more and more subsystem with Rust already.

Honestly, this is a bold prediction, maybe a foregone conclusion to some, but not everybody. It completely remains to be seen.

> It is nonsense to want a new, unproved kernel to provide that level of safety out of a language that has reached 1.0 not very long ago.

Perhaps - but the Rust community has been very vocal for a very long time about how much of an improvement over C/C++ it was already before it reached 1.0. I'm not asking for an "enterprise-grade" kernel yet, just signs of prototypes starting to emerge and the community gathering round them. I realise I worded that badly in my initial post.

New C/C++/asm based hobby kernels are started (and abandoned) everyday on /r/osdev. Nowhere near as many in Rust by a wide margin. Instead the Rust community seems to have placed all their bets on an "outside in" rewrite of the Linux kernel in Rust. While I think this may well be great for Linux in the long term, its a little dissapointing that there is not more momentum for "from scratch" projects yet. Even Linux started as "as hobby, not big and professional like GNU". Which leads to my next point ...

> Personally, I think Linux is plenty good enough, but we have seen the best UNIX can offer. It's time to move on and try something new.

Don't disagree at all. That's why I'm surprised there aren't more up and coming projects in Rust with brand new designs to the degree that there are in C/C++. That's all. Maybe they are there, and I'm just not seeing them.

> New C/C++/asm based hobby kernels are started (and abandoned) everyday on /r/osdev. Nowhere near as many in Rust by a wide margin. Instead the Rust community seems to have placed all their bets on an "outside in" rewrite of the Linux kernel in Rust. While I think this may well be great for Linux in the long term, its a little dissapointing that there is not more momentum for "from scratch" projects yet. Even Linux started as "as hobby, not big and professional like GNU". Which leads to my next point ...

I think you may just be not looking where the rust people are posting. All you're really saying is that they aren't on /r/osdev, and frankly I don't find that surprising. Here are some of the more flagship projects

The biggest rust kernel/os project I'm aware of is https://www.redox-os.org/

It's a bit out of date by now, but this is an excellent guide written in rust: https://os.phil-opp.com/minimal-rust-kernel/

On the embedded side, this is a commercial project that actually "matters": https://github.com/oxidecomputer/hubris

This is a uni-kernel that I've heard about quite a few times: https://github.com/hermitcore/rusty-hermit

Naturally there's a bunch more smaller projects, and maybe larger ones that I haven't heard of.

> Don't disagree at all. That's why I'm surprised there aren't more up and coming projects in Rust with brand new designs to the degree that there are in C/C++. That's all. Maybe they are there, and I'm just not seeing them.

I suppose you might have a point: with the amount of pro-Rust posts filling almost every discussion of C and C++ over the last 5 years or more, all over the web, the time that advocates spent arguing about why C users are ignorant and stubborn could have been spent contributing to a minimal kernel.

> the time that advocates spent arguing about why C users are ignorant and stubborn could have been spent contributing to a minimal kernel.

Problems with that is that:

A) not everyone wants to dabble in writing kernels

B) there are proof of concepts see Redox

C) whatever OS you write there is almost zero chance it will make a dent. So why bother with it? It's grueling work for almost no impact.

> with the amount of pro-Rust posts filling almost every discussion of C and C++ over the last 5 years or more, all over the web, the time that advocates spent arguing about why C users are ignorant and stubborn could have been spent contributing to a minimal kernel

Don't mistake a very small but very very vocal group of zealots for the Rust community at large

> Don't mistake a very small but very very vocal group of zealots for the Rust community at large

Yeah, but we're talking about the small group who continuously jumps into every C discussion on the web. That's still a large enough group to build a new kernel.

> the time that advocates spent arguing about why C users are ignorant and stubborn could have been spent contributing to a minimal kernel.

I didn't want to say it (I have done so bluntly in the past and gotten heavily downvoted for it), but yes that is one conclusion I have reached as well. I sometimes wonder if some of the people who comment that way have ever read the LKMG.

> Projects in C/C++ seem to be making much faster progress eg. SerenityOS than the Rust community. What is holding Rust back in this area? This is a genuine question, not intending to inflame the discussion.

I think one element is manpower. I don't know how many people are at good enough with Rust to write some kernel code, but I'm almost certain that it's way less than the people that can write kernel code in C or C++. C is 51 years old, C++ 38 years old, Rust 12 years old. It is possible for an enterprise-grade, production ready kernel written in Rust to exist. That still leaves the task of actually writing it.

I think this is a real factor. Rust is winning over C/C++ devs to some degree, who are switching to it or adding it to their skillset, but C/C++ devs probably still outnumber them by a factor of, what 10:1? 20:1? Only some of those C/C++ devs have a background in OSDev as well.

I suspect though that Rust is also getting a lot of its fanbase from the Go crowd, or other languages from the webdev side, where there isn't really strong hardware and OSdev skills to begin with.

It's not necessarily just ability, but also availability of jobs. Lots of places need people to help tweak the kernel they run on, so lots of Linux kernel jobs and some BSD kernel jobs, but no jobs to tweak the Rust kernel that doesn't exist yet. Gotta have some real commitment to pay people to build a new kernel from scratch, knowing that it's gonna take a long time to get anything useful.

> I'm really curious why there aren't more enterprise-grade, production ready kernels at this point.

What would be the point? Kernels aren't swappable, and the value of an OS is in the non-kernel parts - drivers and software.

So a new kernel, even if it is enterprise-grade and production ready, won't run all the things that Linux does. Only for very niche cases, it makes sense (bare-metal hypervisors, or example).

> Projects in C/C++ seem to be making much faster progress eg. SerenityOS than the Rust community. What is holding Rust back in this area?

It's slower to write in, maybe? Unlike traditional projects where the language doesn't matter as much as the libraries available, with OS projects having a huge library doesn't help much.

For example, it might be just as fast to write a data processor in Rust as in C++, because the majority of the code is in already written libraries - you just glue together input libraries, database libraries, etc.

My understanding is that Rust is particularly lacking in the hardware interface area - a feature of incredible importance for kernels. In fact, that is the Kernel's primary function - to serve as an interface between user programs and hardware. Without excellent hardware interaction support, it's unlikely to be a good language to write a kernel in.

> It's slower to write in, maybe?

I doubt it. For decades C++ was mocked by Linus as unfit to write kernels in it.

But we saw resurgence with new OS like Haiku and Serenity.

You need luck to be popular, but it's not enough.

Also, outside FOSS UNIX world, C++ has had a presence already in kernels for quite some time.

Even if not for the kernel itself, the drivers make use of C++, naturally a subset, just like the C for kernel space isn't ISO C proper.

I mean, there are several rust kernel/os projects in progress.

One project that's pushing on the boundary of safety and composability is Thesus, which takes language safety to new ground by shifting traditionally OS-level responsibilities like resource management all the way down to typechecks in the language, and also explores a way of updating any core OS component on a live running system. https://github.com/theseus-os/Theseus

There's also KataOS which google just recently announced: https://opensource.googleblog.com/2022/10/announcing-kataos-...

As you note, these things take time, I agree with sibling that none of them are likely to be "enterprise-grade" or "production ready" this decade.

> I'm really curious why there aren't more enterprise-grade, production ready kernels at this point.... Projects in C/C++ seem to be making much faster progress eg. SerenityOS than the Rust community.

I'm not sure you can take anyone (read: any troll) seriously who thinks SerenityOS is an enterprise-grade, production ready kernel.

Should we be writing new kernels for enterprise-y workloads? Why? World has kinda proven it likes things like binary compatibility. It likes for its software to work as it has, and for all the rest of the system to be predictable.

Should we be rewriting such kernels in Rust? Maybe. Where it is justified.

There are quite a few production ready Rust kernels for non-enterprise-y workloads: TockOS, Hubris, etc.

Writing an operating system is hard and laborious. There are many bugs beyond memory and there are already many tools the Linux team uses to make it safer. That you can make a better, more stable version of the Linux kernel with rust is still to be proven. Not arguing that the language is not better than C or that, if Linux was being started today, it wouldn't be a more sensible pick. But the language is just one component among many others that make such a projects successful.

I would actually be very surprised if there was anything nearly as good as Linux written in rust already. I'm not sure why a company would invest the huge amount of resources to get it done by now and, unless the language had some really unprecedented productivity, I don't think a community led protect would've had it finished by now.

> Projects in C/C++ seem to be making much faster progress eg. SerenityOS than the Rust community. What is holding Rust back in this area? This is a genuine question, not intending to inflame the discussion. I'm spending some time learning Rust as I can afford, but am not opinionated one way or the other yet.

You're not wrong, but replace 'SerenityOS' with 'Fuchsia'. Since the latter is a much serious OS that uses Rust for its drivers.

Maybe some day Fuchsia's Zircon kernel will be rewritten in Rust and then we can all come back to this again.

UNIX-like OSes, C/C++ were just not designed for security. It is time we leave UNIX in the past and start on a clean state with the state-of-the-art and little to no legacy cruft.

I suspect the real reason is there's no money in it. Linux may have the image of being "bazaar style" but in reality most of it gets written by full-time corporate employees who get paid to work on it at their day jobs.

Other than audio devices and some classes of storage devices, most hardware is unsound.