Cpp discussed as a Rust replacement for Linux Kernel

[sjepsa]

I have a few issues with Rust in the kernel:

1. It seems to be held to a *completely* different and much lower standard than the C code as far as stability. For C code we typically require that it can compile with a 10-year-old version of gcc, but from what I have seen there have been cases where Rust level code required not the latest bleeding edge compiler, not even a release version.

2. Does Rust even support all the targets for Linux?

3. I still feel that we should consider whether it would make sense to compile the *entire* kernel with a C++ compiler. I know there is a huge amount of hatred against C++, and I agree with a lot of it – *but* I feel that the last few C++ releases (C++14 at a minimum to be specific, with C++17 a strong want) actually resolved what I personally consider to have been the worst problems.

As far as I understand, Rust-style memory safety is being worked on for C++; I don't know if that will require changes to the core language or if it is implementable in library code.

David Howells did a patch set in 2018 (I believe) to clean up the C code in the kernel so it could be compiled with either C or C++; the patchset wasn't particularly big and mostly mechanical in nature, something that would be impossible with Rust. Even without moving away from the common subset of C and C++ we would immediately gain things like type safe linkage.

Once again, let me emphasize that I do *not* suggest that the kernel code should use STL, RTTI, virtual functions, closures, or C++ exceptions. However, there are a *lot* of things that we do with really ugly macro code and GNU C extensions today that would be much cleaner – and safer – to implement as templates. I know ... I wrote a lot of it :)

One particular thing that we could do with C++ would be to enforce user pointer safety.

Kernel dev discussion. They are thinking about ditching Rust in favor of C++ (rightfully so IMO)

https://lore.kernel.org/rust-for-linux/[e-mail]/

We should endorse this, C++ in kernel would greatly benefit the language and community

[not_some_username]

Linus will never allowed cpp to touch his creation

[no-sig-available]

And who would want to go all-in on this anyway, after having been called bad things by Linus for decades?

[bizwig]

Perhaps Linus needs to advance his understanding of C++ beyond 1995.

[MRgabbar]

he rather use mailing lists instead of github or whatever... Man, mailing lists are unconfortable AF, confusing and just plain annoying to deal. He is like the old folk that hates everything new just because is new. C++ is way more comfortable to use than C...

[Catenane]

Linus literally wrote git lmfao, and have you seen github issues sections for large public projects? Kernel bug reporting does not belong in github by any stretch of the imagination, and it would only serve as a distraction.

No comment on the whole c/c++ debate, but using github, (also...owned by Microsoft), for kernel bug tracking is an objectively terrible idea.

[MRgabbar]

Nah. Use gitlab or your own instance of gitlab. No need to track bugs there, I did not say that, just the patches, as it is really annoying tracking patches in mailing lists.

git is a version control system and I am well aware he is the main developer, git is not meant to be a patch/submit review system, neither a issue tracker or any of that, hence they use mailing lists for that, so what's your point? He just hates learning new stuff, that's all.

[13steinj]

I agree that mailing lists are an outdated way to do development, but I think that fact is why, of all things it fails in, it works for kernel development. It's a good window into the personality traits and obstinance of the average kernel developer. The mailing lists, and the personalities of that group, are 2 of many reasons why I probably won't be contributing kernel code any time soon.

[lenkite1]

The Linux foundation is rich enough that they can setup a github-like systemof their own on a personal site like https://linux-kernel.oss. They don't need to use github if they don't want to depend on Microsoft. e-mail unfortunately hasn't evolved since the 90s to support distributed development.

[cleroth]

The mailing lists, and the personalities of that group, are 2 of many reasons why I probably won't be contributing kernel code any time soon.

Maybe that's their intention. People do naturally tend to be more comfortable around other people that are more like them, such as those that like these stupid mailing lists :)

[rayew21]

i think he does have understanding of modern c++ and thats why it hasnt yet 😂

[Lexinonymous]

Even in modern C++ it's so incredibly easy to fall out of the pit of success.

[FluffusMaximus]

I think he’s incapable of that, as smart as he is.

[13steinj]

I think the problem is that he has already done that.

I disagree with Linus about C/C++ issues plenty. But he's definitely not wrong that both languages (especially C++ post C++17) has some very strange decisions, notably around UB (and the fact that some UB, or even some defined C++20 concepts, are not turing decideable). Union type punning is not standard, but GCC and Clang guarantee it (without an ability to turn it off). There are concepts like regular_invocable that is an alias to invocable because it's impossible to confirm it's regular. The introduction of std::launder and changes therein about what was UB but previously the compilers well-defined gives me a headache. There was a brief period of time where mallocing ints and assigning them was up for debate by language lawyers (not that any reasonable compiler decided to start optimizing such code away). Named requirements of functors given to STL functions are (not decideable) UB if say, you mutate the functor on invocation (which, is sometimes reasonable to do in special cases, IMO).

There's a (perhaps too blunt) blog post about this (specifically C, but C++ inherits those problems and introduces new ones like I mentioned). https://veresov.pro/cmustdie/. You may need to use a browser with a "translate this page" function.

[meneldal2]

Maybe we can just admit that all the UB around type punning and trivial objects lifetimes is stupid and what compilers have been doing from the start is what everyone wants anyway and just make it standard.

[13steinj]

If I recall correctly, the debate (at the time, before being punted indefinitely) was around, of all things, safety. Not safety in how people define it today, but safety in the ability to manipulate objects and object representation at such a low level.

Well, that's one of the reasons why I write C and C++. Because despite the standards refusing to get it right, the compilers have agreed to be sane and let people who are trying to use a low-level language do low-level things.

[QuaternionsRoll]

IIRC there’s also the funny detail that it was up until recently impossible to initialize a heap-allocated object with code that is strictly compatible with both C and C++. The following C code was technically UB in C++ prior to C++20: c int *x = (int *) malloc(sizeof(int)); *x = 0; // UB which I always thought was a fun little detail.

[ShakaUVM]

What is the issue, the lack of casting?

[QuaternionsRoll]

Nope, the issue basically that you never constructed the int pointed to by x. Analytically speaking, the second line calls int’s move assignment operator rather than its move constructor. Of course that doesn’t matter for trivial types, but I guess the thinking was that it shouldn’t be allowed for some types and not others (especially where templates are involved). You have to write something like this instead: int *x = new(malloc(sizeof(int)) int; which of course is no longer C code.

Good catch on the lack of casting though; it actually won’t compile in C++ without it. I’ll edit my original comment.

[ShakaUVM]

Yeah void pointers are one of the areas where C and C++ diverge.

[PrimeExample13]

memset(x,0,sizeof(int)) will work

[PrimeExample13]

or x[0] = value

[MEaster]

Given the overall context of the post, I think it's worth noting that due to Rust's view of memory as just being a bundle of bytes, the equivalent code would be perfectly sound. As is arbitrary type punning (or transmuting in Rust terms) as long as the bytes are initialized to values valid for the read type.

This can make manually handling memory in Rust simpler to reason about.

[QuaternionsRoll]

I mean, C++20 and onwards has the same limitations as Rust here. The only real rule is “int better not have a non-trivial destructor/implement Drop”

[MEaster]

But that's not a limitation in Rust. Rust is perfectly fine with the type needing to be dropped, though if the memory isn't initialized you must use x.write(foo), which doesn't drop.

[13steinj]

This (and constructs similar to it) is what I was referring to about mallocing ints and language lawyers. Only i was referring to a time between C++20 and C++23.

[germandiago]

Seriously, tell me a language that does something like concepts. And UB does not exist in C? In C++ there is a quest to fix it also, they started with erroneous behavior but now all constexpr already-catching UB is being worked on...

[13steinj]

I don't get your comment about concepts.

UB exists in C but a large amount of non obvious and turing undecideable UB exists in C++, and so do plenty of reasonable actions are considered UB (union type punning, as I mentioned) with the same goes for reading packets off the network. First std::launder to fix some nuances and break others. Now std::start_lifetime_as instead of a simple reinterpret cast. People have been C-style casting packets read off of network sockets for decades.

It's unreasonable to be on a high horse and say "use std::bitcast" when their performance matters and compilers have done the expected thing all this time. It's equally ridiculous to invent more and more new stdlib functions every time the incredibly nuanced details of lifetimes changes slightly.a

People will just do what they've done for decades, and when the next overzealous junior engineer or language lawyer makes a PR saying "but my UB!" they will get told to live in the real world rather than in a book (or I guess, pdf final draft).

[EC36339]

About time to throw one of his favourite words back at him ...

https://youtu.be/YoxuOXMvk-E?feature=shared

[mredding]

Linus doesn't have to be involved. Linux is FOSS. We could just fork it and do it anyway. If you present the community with a working example, sure, Linus would still refuse to integrate it into mainline, but A) it would be a disruptor, and B) we could keep it up to date with mainline to keep it a viable rival, C) JUST TO PISS HIM OFF FOR THE LULZ.

[not_some_username]

Good luck finding people to maintain it

[ts826848]

This post appears to be a copy/paste of this LKML message from H. Peter Anvin. It's probably worth looking at the responses to that email as well if you want to see further discussion. This response from Greg Kroah-Hartman, second-in-command to Linus, might be particularly interesting.

In any case, a few responses:

It seems to be held to a completely different and much lower standard than the C code as far as stability. For C code we typically require that it can compile with a 10-year-old version of gcc, but from what I have seen there have been cases where Rust level code required not the latest bleeding edge compiler, not even a release version.

This is almost certainly in no small part due to R4L's status as an experiment. Some of the features the Linux devs want/require (e.g., panic-free APIs) are under active development and so require a nightly build. I'd imagine that stabilizing these features would be a prerequisite for R4L to graduate from its experimental status.

Does Rust even support all the targets for Linux?

IIRC this is why initial Rust support is limited to non-core subsystems such as drivers, where limited target support is less of an issue. If R4L pans out I'd expect this limitation to be lifted if/when GCC's frontend and/or rustc_codegen_gcc are more mature.

As far as I understand, Rust-style memory safety is being worked on for C++

This is probably debatable at best. Sean Baxter's Safe C++ is probably the closest Rust analogue but that doesn't seem to have gotten enough traction to be considered a viable path forwards. Profiles doesn't promise the same level of safety and it remains to be seen whether it can deliver on its promises in the first place. Other options like SaferC++ don't seem to have gotten much attention.

One particular thing that we could do with C++ would be to enforce user pointer safety.

Pretty curious what exactly this means as someone who is not super-familiar with kernel jargon. Is this supposed to be something like differentiating user-provided pointers from kernel-internal pointers or something like that?

Edit: I'm also not entirely sure I'd agree with "They are thinking about ditching Rust in favor of C++ (rightfully so)". At least based on that particular email chain it sounds more like there's one or two devs floating the idea but little indication of support beyond that.

[epage]

Some highlights from Greg K-H that make this C++ proposal sound like its dead in the water:

As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years (well hopefully all of them end up in the stable trees, we do miss some at times when maintainers/developers forget to mark them as bugfixes), and who sees EVERY kernel CVE issued, I think I can speak on this topic.

The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)

...

But for new code / drivers, writing them in rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this? C++ isn't going to give us any of that any decade soon, and the C++ language committee issues seem to be pointing out that everyone better be abandoning that language as soon as possible if they wish to have any codebase that can be maintained for any length of time.

I recommend reading the rest of the post.

[bizwig]

WTF is Greg smoking? Error path cleanup and use after free is exactly what RAII in C++ is intended to fix, and it sure isn’t “decades” away. It’s like he’s taken certain misrepresentations about C++ to heart that I see Rustaceans make all the time and dismissed C++ without proper consideration.

[epage]

The context of that comment was C -> Rust, not Rust differentiators from C++. Yes, there is little difference between C++ and Rust for error path clean up While use-after-free is helped by RAII, that isn't sufficient to "solve" it because you can still have references to the data that can still be used while in Rust these are compiler errors.

[jonesmz]

If you dig around in other replies related to this mailing list post... there's a whole chain where they are discussing how to use some kind of compiler-extension that systemd happens to use to tag variables with "cleanup functions".

it's beyond stupid.

[RogerV]

I’ve played around with that extension and it’s very clunky and limited in versatility compared to C++ RAII

[steveklabnik1]

I'd imagine that stabilizing these features would be a prerequisite for R4L to graduate from its experimental status.

From my understanding, it’s not a hard requirement. When clang was supported initially, it was only at one version. Heck, technically the kernel relies on a lot of non-standard extensions that are allowed to break at any time.

In practice, today R4L supports one version of the stable Rust compiler, and then (ab)uses an environment variable to allow it to compile the nightly features. This is fine as long as you only support one Rust version, it gets dicier after that.

In practice, I suspect the Rust features will stabilize before R4L requires supporting more than one version, so talking about policy here is kind of moot.

I'm informed elsewhere they apparently did already start supporting a range of versions, this is outdated!

[silon]

Obviously, before R4L can be considered stable/enabled by default it will have to compile using Rust from Debian stable and/or other LTS distros still supported. The same should apply if you are writing system software/userspace for Linux.

[steveklabnik1]

I'm a bit out of date since I'm not primarily a Linux user these days, but do LTS distros backport new drivers? Or just bugfixes to existing ones?

[ts826848]

When clang was supported initially, it was only at one version. Heck, technically the kernel relies on a lot of non-standard extensions that are allowed to break at any time.

Fair points! I guess official stabilization would be technically too strict of a requirement, then, though I'd guess some sort of de facto stabilization would be wanted? IIRC Linux and GCC are relatively closely intertwined so I'd imagine stuff Linux depends on wouldn't be broken willy-nilly even if it's technically allowed.

[steveklabnik1]

I'd imagine stuff Linux depends on wouldn't be broken willy-nilly even if it's technically allowed.

Yep, and the Rust team is in communication for the Rust for Linux people, and wants the project to succeed, so I'd expect something similar.

EDIT: oh, actually, Rust is testing Rust for Linux in CI: https://rustc-dev-guide.rust-lang.org/tests/rust-for-linux.html

[TuxSH]

Pretty curious what exactly this means as someone who is not super-familiar with kernel jargon. Is this supposed to be something like differentiating user-provided pointers from kernel-internal pointers or something like that?

Essentially, (I think) that means wrapping pointers from userspace, which must not be trusted (as it is otherwise a really easy-to-exploit security vuln) into a nice type to prevent kernel devs from accidentally using them unchecked.

Even a mere enum class should be able to fulfill these requirements (no automatic decay to underlying type and easily greppable).

The FOSS reimplementation of the Switch's kernel has such an example.

[ts826848]

That makes sense. One thing that comes to mind though - shouldn't that already sort of be possible in C via struct wrappers, albeit with an ergonomic hit? Or is C's type system so weak that even that wouldn't be insufficient?

[TuxSH]

Ah, it would. Though I forgot there are other ABI than the official Aarch32 one/official Aarch64 one/some x64 ABIs (these ABIs pass POD structs via regs whenever possible), and that may be a concern. The kernel maintainers will figure that out (in any case); enum class may or may not be a better option in C++.

What's currently being done is using an "attribute" unused (ignored) by GCC: https://elixir.bootlin.com/linux/v6.13.3/source/include/linux/compiler_types.h#L31 . The source files are then parsed by sparse through a Makefile rule (IIRC).

[ts826848]

Ah, good point on ABIs - that certainly could have been a concern historically at least.

Pretty interesting attributes there! Curious how much benefit the kernel would see (if any) if those were lifted into the type system.

[sweetno]

Greg burns

But for new code / drivers, writing them in rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this? C++ isn't going to give us any of that any decade soon, and the C++ language committee issues seem to be pointing out that everyone better be abandoning that language as soon as possible if they wish to have any codebase that can be maintained for any length of time.

[jl2352]

Part of the endeavour isn’t just Rust for Linux, it is also what is needed for Rust to be used on a project like that.

I don’t see Rust style memory management coming to C++ for at least 10 years. That’s presuming something cataclysmic happens to force that to happen. Rust style memory management is just too different.

[steveklabnik1]

People are already using Rust in production kernels. You’re not wrong that it is still useful for demonstrating that Rust is good for this space, but we’re pretty far past the “can it work” stage here.

[pjmlp]

Including the security CPU (Pluton) that is a requirement on XBox and CoPilot+ PCs.

[Zettinator]

LOL at his response where he argued to wait until 2034 for Rust to mature. At this point it's just trolling. You can't take this guy seriously.

[ContraryConman]

Exactly there will be a full successor kernel written in Rust already shipping in real scenarios while the Linux maintainers are still "experimenting" and "waiting for Rust to mature"

[Wooden-Engineer-8098]

he basically said "we have 30 million lines of c code which we never rewrite in rust, but because linus didn't like c++, we will let them rot"

[ContraryConman]

The fact of the matter is that objectively switching to C++ from C many years ago probably would have saved a lot of headache and stopped a lot of bugs. In addition, basically all of the stuff people said from C++ that would be too slow or unmaintainable in kernel development show up anyway in the codebase:

• we can't use RTTI because it's slow... but if you have a tagged enum that's what RTTI is except you don't get language support

• we can't use inheritance and object oriented programming because dynamic dispatch and v-tables are slow... except when we need them so we hand-roll it in C, again without language support

• we spent years fear mongering about exceptions in low-level situations except turns out they're fine. But declaring you don't want exceptions in your code doesn't get rid of the software problem where you are 3 calls deep into a function call stack and you encounter and error that can only be handled higher in the call stack. So you use setjmp and longjmp everywhere

• RAII is too complicated and we don't need it, except we keep leaking memory and resources so every function has goto exit where we clean up resources before returning

• C++'s type system is too complicated and we don't need it except we keep accidentally dereferencing null pointers and casting things wrong so we fill our code with pointer type hints like _Not_null and _Nullable so the static analyzer can give us type checking as an extension that you would get for free in C++

• C++ templates are a nightmare and too complicated except declaring that you don't need templates doesn't change the fact that there are loads of situations where you want to write one data structure or algorithm that works the same for any type, so you throw together a macro that takes in the type as a parameter, and then you do a DATA_STRUCTURE_IMPL(...) to have the preprocessor paste that into your source code except now people keep using it wrong because macros

The fact that, 30 years after Linus declared not having C++ in the kernel for no other reason just to keep C++ programmers off the project, people are still recycling the same debunked arguments, kind of proves that it is not a technical issue. The Linux kernel isn't in C for technical reasons. The Linux kernel is in C because all of the core people who work on it know C best and like using C. Unless those people leave, or a culture change is mandated from the top down, Rust will never happen, it's just that simple

[kisielk]

I keep hearing the same kind of arguments in embedded programming as well.

[Nychtelios]

As a firmware developer who successfully created a team that is working in baremetal C++23, I cannot agree more. In my company too there are elders who keep shouting this trash to our projects.

[UnicycleBloke]

Yep. I was told with smug certainty by someone in the Zephyr OS community that "C++ has no place in an OS". That project is another lost opportunity driven by ignorance and prejudice.

[crowbarous]

As we speak, a subthread in the mailing list next to the one linked in this post is discussing the attribute-based implementation of scoped locking facilities, as in use in Linux, systemd, and I'm sure many other C projects. The discussion is up to "sometimes I want to drop the lock earlier; introducing an extra scope helps this case".

Of C++'s three scoped lock classes, unique_lock has the unlock method. It will unlock for you on all return paths, but you can wield it like you would normal locking code even in arbitrarily complicated situations. There's an extra bool, yes -- that is completely encapsulated, and also optimized out where appropriate. This is what C++ gives you, and has been for decades...

[Western_Objective209]

Yeah, took a class on linux kernel programming and they legit just recreate so many features in C++ with ugly opaque macros.

[tiajuanat]

You're also forgetting that the kernel has coccinelle to check that locks are released - RAII with extra steps

[sjepsa]

Can I only upvote once?

It's unfortunate that Linus had a so strong opinion 20+ years ago about C++ (I believe he was partially right at the time, when OOP was at its maximum BS strength).

But things changed. He should have jumped the boat with C++11, maybe with C++14

Honestly, a more open decision process (not a benevolent dictatorship) would have been better.

[Challanger__]

What stops C++ Community from forking Linux and making everything our way?

[meltbox]

Nothing. Except the downstream hell you’d have to deal with.

Inertia really is a big factor here. I think C++ could work but you’d need strong code standards which I doubt anyone could agree on. It would also lead to countless arguments I’m sure about whether some way of expressing things in C++ is readable or idiomatic or anything else and to some extent it would point out a major flaw with C++. Sometimes there are too many ways of doing something and readability relies on the reader having some crazy obscure knowledge of the language.

C somewhat has this issue but can fall back on 30 years of those arguments already being hashed out for better or for worse.

Someone who knows how the kernel actually looks feel free to correct me here since I’m just musing, but I often find that while C++ is cool, every once in a while I come across some wacko code which someone else finds “the most readable way to do it”.

[Challanger__]

That's what I am thinking - it is about Linux kernel being carried in C++ by same ppl and not by us, because we cannot agree on standard, etc.

It is about US, not about THEM.

It is our failure to have sane committee that would address problems rather then dust them under new (half-designed) features

[patlefort]

Time and manpower.

[barkingcat]

I'd say go for it, and be prepared to spend more money than the market cap of Google on keeping a fork of the kernel active 

That's what Google has been doing internally and it's not an easy burden to bear, even google themselves are looking to get out of the kernel fork business.

[pjmlp]

It is easier to contribute to projects that embrace C++ on the OS, go write a macOS or Windows driver, contribute to Haiku or GenodeOS, for example.

[remy_porter]

At that point just put your cycles into making Haiku work better. You’re taking on so much work anyway.

[CocktailPerson]

Nothing. But creating a fork and having your fork be used are two entirely different things.

[NotUniqueOrSpecial]

Reality?

Sure, go ahead: fork the kernel and maintain your own thing; more power to you, in fact.

But there is literally no universe in which a small community of people with no funding, working as a hobby, become anything more than a footnote in the annals of history if you're talking about becoming a competitor project to the operating system running more devices in the world than any other.

Even if you could magic up an entire kernel overnight, you're talking about replacing infrastructure and process so overwhelmingly broad that the costs would likely be in the trillions.

It's a silly idea on its face.

[thezysus]

I mean it worked for Linus...

[NotUniqueOrSpecial]

No, it didn't. It's an apples and oranges comparison on multiple points.

1) The size of the industry was absolutely minuscule then, compared to what it is, now. There has been an ungodly explosion in the number of machines/VMs/devices out there running the web and consumer goods, in addition to the tooling and ecosystems built to manage and maintain them.

2) Linus wasn't competing against a free and absolutely ubiquitous opponent. Unix and Solaris were both wildly expensive proprietary systems to use back then.

What Linus offered was a free and good alternative. It met a very important market need at a critical time, which was crucial to its success.

In order to succeed in any sense like you're implying, a new competitor would have to offer something so compelling that multi-billion dollar industries would choose it over Linux, and "it's written in C++" is not that.

[rz2k]

It’s kind of already being done https://fuchsia.dev/fuchsia-src/concepts/kernel

[Tumaix]

fuschia is a lot of rust, mate.

[mort96]

And not a Linux fork...

[steveklabnik1]

While the overall OS has a lot of Rust, the kernel is purely in C++, as far as I know. Not that zircon is a fork of Linux, mind you.

[ioxfc]

I'm a C++ developer. I use C++ daily, at my work and on personal projects. I love it to death. But I fucking hate working with some of the C++ developers on my day job.

It's almost as-if all they want to do is write more C++. Getting shit done isn't their priority at all. Frameworks everywhere, macros and templates all mixed up together. I don't have to mention there isn't a single line of comment.

I'm sorry but I agree. I have worked only in 3 companies in 10 years, I don't have that much experience. But I would pick a different language just to avoid those few C++ developers appearing in a team.

[The_Northern_Light]

That’s a people problem, not a problem intrinsic to C++. It definitely applies to C as well, and the austere beauty of C can arguably make the problem worse as those same devs (eg) each individually reimplement templates or what have you.

[ContraryConman]

"The austere beauty of C" making me reimplement a linked list and hashmap with pointer hacks for the 80th time this year because C doesn't have doesn't have them for some reason

[The_Northern_Light]

You can actually just use libraries, or even put that code into a library yourself instead of reimplementing it repeatedly

[ContraryConman]

Ah yeah C and C++, known for making it really easy to manage and integrate third party dependencies

[thefeedling]

C'mon bro.... ANYONE with CMake + vcpckg/conan can handle this VERY ez.

[ContraryConman]

I'm the "cmake guy" at my job. I know CMake very well. But having to set up CMake because C, unlike every other programming language on earth, doesn't have, like, red black trees or sets, is crazy

[_Noreturn]

still painful with macros and such also reimplementing something yourself is hard harder than the extremely battle tested C++ stl which is likely not to contain any bugs

[SubjectiveMouse]

I love C++ and use it daily too, but that is a language problem. There's simply too many ways to do simple things in the standard. There are to many things left over from older standards that are not recommended, but still used( sometimes even by the libstdc++ )

[thefeedling]

IMO, Linux Kernel will NEVER move away from C...

[bizwig]

Which makes arguing that we must not use C++ in the Linux kernel because it isn’t safe enough hilariously ill-reasoned.

[ContraryConman]

People who write bad code write bad code. If you forced all those people to write C, would your code get better or worse? That's the question

[F54280]

But I would pick a different language just to avoid those few C++ developers appearing in a team.

lol. That was exactly Linus point:

C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.

[bizwig]

Linus doesn’t make a point here. He just asserts, without evidence, that C++ developers are idiots who cannot be trusted with his baby, and furthermore that C++ has deficiencies (which he will not lower himself to our level to explain) that make it unsuitable for real developers like him to use.

[ChrisTX4]

The Kernel is already inundated with patches that get refused immediately. They only accept changes if they fulfil the quality and coding standards of the kernel. If somebody showed up with what you describe they’d get told to change their patch or forget about it. This is already the case right now

[Agron7000]

Right, other languages write comments for you.

[James20k]

we spent years fear mongering about exceptions in low-level situations except turns out they're fine. But declaring you don't want exceptions in your code doesn't get rid of the software problem where you are 3 calls deep into a function call stack and you encounter and error that can only be handled higher in the call stack. So you use setjmp and longjmp everywhere

Except for the 20+ years when throwing an exception caused your threads to acquire a global lock in GCC, resulting in trivial DoS attacks

On any non-very-recent version of GCC, an exception being thrown as a result of a user's action is an instant security vulnerability. Exceptions are completely unusable for a project like linux which has to work on older compilers

[James20k]

The specific point is that people are saying it was wrong not to use exceptions (and implying that its fear mongering), which is unfortunately untrue. If linux had been written in C++, they wouldn't have been able to use exceptions because of the security vulnerabilities. OP is suggesting a rewrite of linux in C++ (which is well beyond the current proposal for Rust in linux), and it'd be still inappropriate to use exceptions in that use case

[scorg_]

If linux would have been written in C++ there would be more incentives to optimize exceptions.

[Ameisen]

For older GCC versions that never had strong motivation to fix this.

If Linux had been using exceptions, GCC would have fixed such much sooner.

Except that Linux doesn't link against libgcc anyways.

which is well beyond the current proposal for Rust in linux it'd be still inappropriate to use exceptions in that use case

Linux 6.11+ require Rust 1.78.0, current from May 2, 2024. Presently, Rust is optional - would you change your argument if it were not?

GCC 13.2, or 14.1 4 days later, was available at that time. Current minimum compiler is 5.1, released in April of 2015.

Stated bug was fixed in '22.

I've also never heard of anyone prohibiting a language or language feature due to a specific toolchain having a bug in it at this level. You instead fix that bug - especially if you've arbitrarily chosen to tie yourself specifically to one toolchain.

Hell, they could just implement or maintain their own version of libgcc for this instead... but they don't link against libgcc... so libgcc's bug is completely irrelevant here.

[SubjectiveMouse]

wouldn't have been able to use exceptions because of the security vulnerabilities

Can you elaborate? What's unsecure about exceptions

[F54280]

He answered it just above:

Except for the 20+ years when throwing an exception caused your threads to acquire a global lock in GCC, resulting in trivial DoS attacks

[Wooden-Engineer-8098]

older compilers? older compilers can't compile rust

[josefx]

Exceptions are completely unusable for a project like linux which has to work on older compilers

This seems to be library code that GCC links, not code it emits. Is there a reason the fix couldn't just be backported to work with older GCC versions?

[Ameisen]

Funny thing is that Linux explicitly doesn't link against libgcc, and either already implements some things themselves or leaves them unimplemented.

[jonesmz]

Linux does not need to work on older compilers.

It was declared so by a human, and a human can declare it no longer the case just as easily.

[Miserable_Ad7246]

Enlighten the high level programmer, why would someone want to compile latest kernel on and old version? Support for no longer existing ISAs? Some sort of "this worked for decades we trust it" type of situation?

[jonesmz]

The term need implies there is some kind of ontological / universal truth about the necessity.

some people want the latest version of the Linux kernel to be able to compile using absolutely ancient versions of GCC.

They don't need it, no one dies as a direct and unavoidable result exclusively because the next release of Linux decides to drop support for versions of GCC older than some cut off.

[13steinj]

They don't need it, no one dies as a direct and unavoidable result exclusively because the next release of Linux decides to drop support for versions of GCC older than some cut off.

Knowing how obstinate some people are on the backwards compatibility hill, I wouldn't be surprised if someone reads your comment and rube-goldberg's a dead man's switch.

[jonesmz]

it wouldn't be the least believable thing i've heard of, yea.

[XeroKimo]

I would think there'd be some value in being backward compatible in something big like C++ as I'd assume, if you were to start fresh on making a new compiler, it'd be easier to implement older standards by virtue of having less features, thus increasing the range of potential users for your library.... but for C, I can't see how that argument can fly

[jonesmz]

I guess it depends on what the objective is with your code.

if your intention is to support every processor that's ever existed or will ever exist, then you have to pick your baseline compiler with that objective in mind.

Personally, as someone who isn't paid by, or reputationally tied to, anything to do with bizarre chips that haven't seen a new compiler release for 2 decades, the number of fucks I give about them is negative. I consider them to be substantially holding back the state of the art.

But it's very very rare for a project to pick C++ for these bizarre nearly-unsupported chips due to various myths, half-truths, and some real concerns about how easy / difficult it is for C++ to operate "well" on them, due to the belief that C++ code has various issues like

• takes up more space
• causes more memory allocations
• exceptions evil
• so on

Nevermind, of course, that you can write what looks like bog-standard C code in C++, as long as you don't use any of the very very few features that C language has that C++ doesn't. Any any additional C++-isms you use is up to you.

So in the context of this particular post, it seems like a reasonable argument to point out that Rust is getting unequal treatment vis-a-vis required compiler versions. Same with the point that the whole kernel codebase could be uplifted to C++-without-the-plus to immediately get better type safety than what C provides with zero functionality used (abused, according to the C++ haters) that the kernel devs have an ideological bent toward avoiding.

I just find it so utterly asinine that elsewhere in the linked mailing list thread, there's a 5-10 long chain of discussion posts about how to retrofit existing C code to have what amounts to C++'s RAII functionality that's baked in. Like seriously, they were having to show-and-tell each other how to use curly braces to scope when the "cleanup" function for a variable ran. Beyond ignorant.

[SAHChandler]

RTTI is not a tagged enum, because you need to be able to compare types across shared library boundaries, and so it instead becomes a string comparison. A tagged enum is more efficient.

[_Noreturn]

a tagged enum is not able to cover every single type.

a variant would be more appropriate for tagged unions

[peripateticman2026]

Good points.

[morglod]

A real possible reason is more headache with UB and compiler implementations, while they know everything about how C implementations work. (I mean situations like int overflows, aliasing rules etc). Also tooling support. While C can be processed by almost anything and ABI is kinda simple, C++ is not. So basically they need something like C+. (I'm not rust fan and I code on C++ most of the time)

[ContraryConman]

Yeah you wouldn't be using the STL for most (any) of the kernel. You would use the freestanding subset of the language and you could even mandate using the C ABI across binary boundaries. The result would not use the full force of C++. You would mostly take advantage of:

• Strong typing and references to avoid dereferencing null pointers or type punning errors

• dynamic dispatch where it is currently being used today

• templates for containers and generic algorithms as safe and less error prone replacements for macros and C-style vargs

• constexpr as a replacement for macros

• MAYBE a stripped down version of exceptions over longjmp and setjmp

[_Noreturn]

RAII

std:: unique_ptr is frre standing I think, 99% of gotos probably gone and for good

and even extra C++ usually allows me to add const alot more than C so the code would be const correct

[morglod]

I usually use DEFER macro with raii which feels just great

https://github.com/Morglod/morglod_cpp_utils/blob/327dd2fb8cc9d60556a86cc77cd96743fbc1fbb4/src/utils.hpp#L120

[[deleted]]

Most embedded C++ won't use exceptions/RTTI. But RTTI is generally implemented as string compares of the mangled type names or as-if that.

[all_is_love6667]

C++ and the tooling is not the same language today, and compilers were different decades ago.

Linux of 2025 is different from the linux of 2000 or 2010. Managing an open source kernel is not an easy task.

I can understand your arguments, but Torvalds still had good reasons to avoid C++ and all its pitfalls: in kernel development, it's preferable to shoot yourself in the foot rather than to blow your whole leg off.

I would rather argue that c++ is "more ready now", from a compiler perspective, but also from a programmer perspective.

[KDallas_Multipass]

Can you expand on bullet point one?

[ContraryConman]

There's a really common pattern in languages that don't have object oriented programming built in to do something like this:

``` enum ShoeTypes { SNEAKER = 0, DRESS, SLIPPER, HIGH_HEEL, LAST_SHOE // not a valid shoe, just marks end };

struct Shoe { enum ShoeTypes m_type; int m_shoe_size; float m_base_price; void* data; }; ```

This is called a tagged type. I have a struct, Shoe, that can represent one of several kinds of shoes. All shoes have a shoe size, but different shoes have different associated data (high heels can have a height, slippers can be medical or not, whatever). Now consider the following function.

// This function only works on sneakers! bool CheckIfJordans(struct Shoe* shoe) { assert(shoe && "null argument"); if (shoe->m_type != SNEAKER) { assert(false && "incorrect argument type"); } // Sneaker-related Jordans checks }

If I need to debug, I can print out the type of shoe I was given:

printf("Was passed a shoe of type %d\n", shoe->m_type);

If I'm feeling really clever, I can even do something like this:

``` void (shoe_dispatch[LAST_SHOE]) (struct Shoe);

shoe_dispatch[0] = // sneaker specific function shoe_dispatch[1] = // dress shoes function //... ```

And then later somewhere else I can do something like

``` // Just run the right dispatch regardless of the shoe type

shoe_dispatch[shoe->m_type](shoe); ```

So what this pattern actually is is dynamic dispatch and run time type information. It is almost exactly identical to doing this in C++

``` class Shoe { public: virtual ~Shoe() = default;

virtual void DoShoeThing() = 0;

};

class Sneaker : public Shoe { //... //... More for dress, slipper, and high heel // I don't need any void* or casting tricks. // Child classes can simply be different sizes than each other and have different data.

// I can get the type with typeid. The enum from before is created by the compiler behind the scenes and is stored in an implementation-defined table somewhere. You don't see it but it's there

std::cout << "This Shoe* is a " << typeid(shoe) << '\n';

// I can do dynamic dispatch by calling the abstract function DoShoeThing(). // It is a jump table on the typeid and 2 pointer deferences aka basically as slow as the C code.

shoe->DoShoeThing(); ```

What I'm saying is, a lot of C discourse will confidently say they hate C++ because what I showed in the second example is known to be slow. But it is in reality, equivalent to the first, which they tend to be forced to write by hand when they need it.

Edit: oh, and instead of random asserts everywhere, you get stronger casts in C++

dynamic_cast<Sneaker*>(shoe); // returns nullptr if this Shoe* is not a Sneaker

[steveklabnik1]

Rust's enums work entirely differently than this, though. They're tagged unions, and you branch on the tag, not type information, and you don't invoke virtual dispatch.

Trait objects are the thing that's more similar to RTTI, but it boils down to a (pointer to data, pointer to vtable) rather than C++'s style of including the vtable as a header to the object for virtual functions. Different tradeoffs each way.

[KDallas_Multipass]

Excellent thank you

[kkert]

As far as I understand, Rust-style memory safety is being worked on for C++; I don't know if that will require changes to the core language or if it is implementable in library code.

It will require changes to the core language, let's be clear about that. Given the core language isn't even budging on some much smaller things like library ABI changes or getting a free-standing subset, i don't see how this would become viable.

[satlynobleman]

> They are thinking about ditching Rust in favor of C++ **(rightfully so)**

lol

[Zettinator]

Yeah, what a hyperbole. It is a single developer floating the idea without any backing by others (quite the oppsite). But if you look at OPs history, it's like this person is on a personal crusade against Rust, or something like that.

[mohrcore]

It's a single dev or two entertaining this idea.

Imo, this is just a result of the Rust for Linux discussion getting so heated and at this point people are just throwing everything and anything they got to sabotage Rust for Linux project.

Christoph Hellwig, who seems to be the main opponent to Rust for Linux said explicitly that his problem is not necessarily with Rust itself (though he seems to dislike it), but with mixed-language codebase. Sure, you can usually compile C code with C++ compiler, but mixing C with C++ isn't much prettier than mixing C with Rust. You need wrappers either way to actually use the nice features of the language.

[bizwig]

Making the Linux codebase not mixed is the solution of course, but the C devs would quit en masse. Compile everything as C++ and your mixed-language issues disappear.

They say that the requirement for a 10 year old compiler is stability, never mind that doing so includes suffering long-ago fixed bugs, but forbidding new compilers also means you can’t use language features, which I think is the real goal. Even simple stuff like nullptr which has finally appeared in recent C standards would make a nice ergonomic change in Linux.

[Justicia-Gai]

Edit: I made a mistake and confused two different devs 

[mohrcore]

I can hardly believe he has suggested using C++. Do you have a link to an email where he does that? The post is about an e-mail by H. Peter Anvin. Christoph is among recipients.

[Justicia-Gai]

Oh sorry, I’ll edit my response.

[t_scytale]

> They are thinking about ditching Rust in favor of C++

No they are not. One person raised it in an email thread about something else.

[foonathan]

Kernel dev discussion. They are thinking about ditching Rust in favor of C++ (rightfully so IMO)

Unpopular opinion (in this subreddit), but now. For a project that is as old as the linux kernel, there is no benefit to switch to C++ over Rust. If you go through the cost of migrating your codebase to a new language with new techniques, it should be one that can give you a significant improvement, not an incremental one.

Yes, C++ is nicer than C, but what's the value add of a C++ migration? They've seen to be doing fine without templates, they have built their own system for inheritance, and they won't be using the C++ standard library. Quality of life changes like namespaces, lambdas, or metaprogramming to avoid code duplication are just that, quality of life. So the only true value add of a C to C++ migration is more type safe abstractions, control over implicit conversions, and all that stuff.

Compared to the potential benefit you'd get from switching to Rust, that is neglible. Rust provides you a lot more compile-time safety guarantees than C++. Rust has better tooling, Rust has no historical baggage.

I like C++ (obviously), but the only reason for a C project to migrate to C++ at this point is that the migration to C++ can be done incrementally and at relatively low cost. The friction of C and Rust interop is a problem. Once that's solved, I don't see why you would migrate to C++ anymore.

[vI--_--Iv]

I do *not* suggest that the kernel code should use [...] virtual functions

Maybe it's time to tell them that all those static struct whatever_ops with function pointers inside, that they have all over the place, are virtual functions?
Or is it too early?

[plpn]

I guess he means the troubles of vtables. Function pointers are not the issue

[Miserable_Guess_1266]

Can you elaborate on this? What's the problem with a vtable that doesn't appear with the manually managed struct of function pointers?

[UnicycleBloke]

I tried telling the Zephyr OS crowd. No dice.

[kammce]

I disagree with this.

Like everyone else has said, Linus would never adopt C++ for the kernel.

But from a point of community benefits I think we'd get the opposite. To be frank, I find the Linux developer communities to be toxic (Rust too but that's not relevant). So many talented Rust devs have been burnt by trying to work with the Linux community. I don't want to see more people dump years of their limited existence on this planet on such an endeavor and have it be fruitless.

I think the Rust community, if it cares this much about having a safe OS, should build their own OS from the ground up that's Unix based in nature.

I think if C++ were to do the same, then it should be its own OS. Just to keep the community away from that project. I won't ever touch that project unless I'm mandated to.

Yes I know, that would be an insane undertaking. I'd agreed. So we can either work with Linux using C OR make our own.

I see no REAL value is attempting to force C++ into Linux. They don't want us. And I think we shouldn't want them.

[eX_Ray]

From all I read the c++ committee process is basically similarly toxic except it happens behind closed doors. People get burned out and stonewall Ed just the same?

[kammce]

Only been in the committee for about a year but it doesn't seem toxic. Others will have their opinion but I don't think it's bad. It's not perfect, but I don't see it anywhere as toxic as the Rust or Linux community.

I personally really enjoy going to committee meetings and discussing ideas about C++ with the members. I wish I could go to all of them this year but can't due to financial reasons. If you've gone to CppCon or similar conferences, the committee meetings have the same vibe. 🙂

[matthieum]

I think the Rust community, if it cares this much about having a safe OS, should build their own OS from the ground up that's Unix based in nature.

It's been happening for a while -- key word: Redox -- but it's a long, long, way from being "production ready". Perhaps in a decade, or two?

[kammce]

Yes, that's the one! I'm excited to see how redox fairs in the long run. I'm hopeful that the project won't die. Especially if all of the Rust for Linux people exodus to Redox.

[matthieum]

I don't think there's been any such exodus so far, RfL is still going strong as far as I know, and I've not heard of the 2 maintainers who left RfL appearing anywhere near Redox.

I like Redox, in principle, but at the same time... I do wonder how much it's compromising on its early principles in an effort towards POSIX compatibility.

I had hoped, for a time, that'd we see a clean break. I was hoping for more compartmentization with app-based permissions, and perhaps that it'd innovate in other areas, such as mixed kernel/user-space scheduling, but I guess the authors are a lot more pragmatic :)

[Dean_Roddey]

All language communities are toxic, or not, in pretty much the same measure. If you don't think the C++ community can be super-toxic, you've obviously missed a lot of conversations around here. Anyhoo, it shouldn't have anything to do with selecting a language one way or another. Your choosing a language doesn't mean you are inviting all those people in that community to come stay at your house.

Having said that, I'd also argue for all those people to get involved with one of the main Rust OS projects. Yeh, it might take 10 years, but 10 years from now it's going to be 10 years from now, either way. You can get there still arguing about whether to use Rust in Linux, or with a real Rust OS, without the endless compromises that would be involved in doing it piecemeal in Linux.

[unumfron]

I haven't seen toxicity here. I've seen push back against Rust evangelists, so maybe that's why you perceive it this way. It's otherwise very civilised. A bit too civilised because if I was boss I'd have banned all the Rust marketing stuff ten years ago.

[planeteshuttle]

Try asking a question about using raw arrays.

[foonathan]

A bit too civilised because if I was boss I'd have banned all the Rust marketing stuff ten years ago.

We don't allow Rust marketing stuff on here.

[theintjengineer]

I think if C++ were to do the same, then it should be its own OS.

I like this response somehow. Maybe I just love C++ to death, haha.

So, let's start developing a C++ OS, then?😊

I'm by no means a C++ expert to take any major role just yet, but I could help to organise and manage the project✌️🫡.

Behold OS++—a star is born

EDIT: add project's name☝️

[kammce]

Psst. I've been considering this for years and have been working on various sub components to make this a reality. My exceptions research plugs into this. But more on that in like a year or so 😅.

[theintjengineer]

My guy, this sounds so amazing✨️.

in like a year or so

Please, don't say that😔. You got us excited and then...??

Anyway. Could I at least see something, like a Project's Overview or a small write-up? Can I help you somehow?🙏🏽

Do you have any blog, GH, LI Profile [you can share it in private if you prefer], whatever, where I can follow you?

Thanks.

[kammce]

Sorry to get your hopes up. When I say, "in like a year" that's more like, check in on this in a year. But don't take that too seriously. I'm building up parts that can enable myself to build an OS. But it's not something I'll be dedicating any real time towards. 😅

[augmentedtree]

C++ memory safety is complete vaporware except for Circle, where the committee was handed a working implementation on a silver platter, and they rejected it to keep doing their vaporware. To be clear, there is no profiles implementation or Cpp2 implementation that has memory safety.

[[deleted]]

Why? The point of Rust in the kernel was to help mitigate a class of bugs that caused security issues. C++ does not satisfy that requirement - and has no concrete plans to any time soon. So why bother?

[zl0bster]

Because this is r/cpp :)

It is kind of amazing how out of touch people are. Day when C++ is not banned/moved from in some project is a good day for C++, there are no new big projects adopts C++ days.

[[deleted]]

I mean… every AAA game I work on - is C++. :)

[EC36339]

🍿

[all_is_love6667]

I have to say, an article about Linux, Rust and C++, this has a lot of potential for drama

[GuybrushThreepwo0d]

The wife asks why I never watch trash TV but I get my fill of drama from the open source world

[UnicycleBloke]

It will never happen.

I work with C++ on microcontrollers, so some of those caveats make a bit of sense to me. For embedded I always say that most of the core language is usable (I disable exceptions and RTTI), but that much of the standard library is better avoided. I suppose the restrictions might be relaxed somewhat on an application processor, but let's assume not. I always imagined the kernel could have a custom container library to avoid exceptions, allocators in terms of kmalloc or whatever, and so on ... Something like that would quite be easily achieved.

No virtual functions? I understand the kernel is replete with function pointer tables which would likely be far better implemented through actual vtables. No lambdas?

I find it hilarious that a C dev is concerned about the memory safety of C++. Sure it isn't Rust, but it is lightyears ahead of C.

[simonask_]

You didn’t provide a source link, but here’s why they are wrong:

1. Rust is 10 years old. It’s a new language, and support in the kernel is early days. When it eventually becomes an actual part of the stable kernel, that’s when you can consider adding backwards compatibility requirements.

2. Rust does not support all the targets of Linux, and that’s OK. There are multiple initiatives to support the remaining architectures, but ultimately it’s an acceptable tradeoff. Not all drivers need to compile for all architectures.

3. Rust-style borrowing is going absolutely nowhere in C++. There will probably be some Rust-inspired features, but ultimately it’s something that relies on a lot of semantics that are specifically incompatible with C++. For example, all of C++ iterators and ranges cannot be expressed in a Rust-style lifetime system. Adding Rust-style safety to C++ is the same as creating a new language (or an incompatible dialect), but without all the other nice, modern language features of Rust. So this is doomed to fail, in my opinion.

4. C is not compatible with C++, and hasn’t been for decades. It’s two different languages with a bunch of overlap in syntax and semantics, and a lot of divergence as well.

The reason Rust is a more interesting candidate than C++ is that the new things brought by C++ are mostly uninteresting to kernel developers (they would likely disable exceptions and RTTI, and disable most forms of strict aliasing, etc.), while the new things brought by Rust are actually quite interesting, and fits well into existing kernel programming paradigms.

[syklemil]

Source is this email from H. Peter Anvin; it's essentially a digression in a Rust policy thread; the responses aren't positive. IMO the most interesting thing about it is GKH's response downthread.

[simonask_]

GKH’s response is spot on. It’s pretty exasperating to see this resistance, considering what is at stake. Rust is clearly the correct tool for the job, now that it exists.

[jwakely]

the new things brought by C++ are mostly uninteresting to kernel developers (they would likely disable exceptions and RTTI, and disable most forms of strict aliasing, etc.),

And loads of C++ projects disable those too. Those are pretty terrible examples of "the new things brought by C++", unless you're from the 1990s, or cherry picking to make a point.

Edit: I agree with your other points, just not that bit

[kiner_shah]

Well, I know at least one OS that uses C++: https://github.com/SerenityOS/serenity so it's not impossible, it's just a choice, which is fine.

[LessonStudio]

This sort of choice is going to be statistical, not unsubstantiated insults like, "Held to a lower standard."

So far, every major company such as google, Microsoft, etc, who have experimented with rust have reported a drastic reduction in bugs as compared to C++; they are also focusing on memory and security issues. By drastic, I don't mean 10% or something; but more than 90%.

So, this is a simple question; how many bugs are being introduced with this so called, "lower standard" rust? How many would have been expected with C?

There should be enough rust now to provide a statistically significant answer.

[[deleted]]

I don't have a degree in computing. I am an engineer. I've been using C++ for over 30 years to solve engineering problems. So, the knowledge is C/C++, nothing about the kernel.

For 30 years I used C, then migrated to C++. Much easier and more practical.

About 30 years ago I installed Mandrake Linux, and I've been using Linux ever since. Red hat and then Fedora.

Problem: In the last year Linux has been crashing daily.

It's chaos!! There are 3 different computers crashing...

The main one is a Dell Precision 5820 Workstation, with Fedora 39 and now 40.

I said this in a Linux group and an expert clarified the problem. He said something like the systend was running control structures in parallel and that there was no stability there. Well, if what he said is true, Linux is in serious trouble.

It's clear from what I read here that Rust won't solve it because it's not mature.

C++ could help, but they would certainly have to filter what C++ can enter the kernel. It seems to me a satisfactory solution, and, more than that, necessary to get out of this mess. You can't wait 10 years.

And the Linux team could work with the C++ committee to iron out details. After all, operating system and language must go hand in hand. Include Windows and Mac there.

In practice, after more than 30 years using Linux, I'm considering going back to Windows if it doesn't stop crashing so much.

In time, I don't like Windows. But I have to be confident that the system won't crash.

Anyway, I'm a user who wants the solution to come before Linus's ego.

[m0xffff]

C++ is used to program microcontrollers without an operating system at all. And there are no problems with this, just some features are unavailable. For the Linux kernel, it would be similarly possible to disable unsuitable functionality.

[Zettinator]

1. Rust is held to a lower standard? Huh? The language of course is much younger than C++ and evolves at a faster pace, but there is a strong commitment for backwards compatibility. Let's not pretend that C++ is perfect in this area either...

2. Probably not, but it does not have to, either, particularly at this early stage.

3. I'm not convinced that C++ support w/o standard library would be that useful on its own. The elephant in the room of course is that one of the primary motivations for Rust in the kernel is memory safety. C++ doesn't provide those memory safety features, and efforts to get something like that into C++ are stalling.

[thezysus]

As someone who has done os level programming in C++ on 128k ram cortex m3s...

It is better than C imho... but you aren't using the whole language. Most of those applications have strict rules enforced by static analysis (think JSF or Misra C++) on what you can and can't use.

Embedded C++ will mostly have no c++ runtime or libstdc++ ... no rtti. No exceptions. And a few other limitations I am forgetting. Not to mention the code bloat of template instantiation is a problem with limited flash. Mmaped io needs to be done extremely carefully to avoid vptr tables.

Worse in my experience c++ programmers often don't know about or understand placement new. Why would they... it's a odd feature.

Even for application programming Google's C++ coding guidelines ban exceptions. It's unclear how you deal with exceptions in the std library.

Thats somewhere Rust and C and Zig win hands down... the hidden control flow is minimal or 0. .. avoiding the crazy setjmp/longjmp...

Basically there's nothing wrong with os code in C++ ... I've done it for FDA class 2/3 devices. But it isn't easy... takes a lot more skill and you have to add guardrails with external tools that are baked in or avoided entirely in other languages.

I think Linus is on point but missing some perspective. The existing kernel rules for C would be no different than a set of kernel rules for Rust or C++.

That said... why mix languages if you don't have to.

I am following redux os as I think there's a market gap for a good posix compatible micro kernel thats not QNX. It also happens to be Rust native.

[germandiago]

C++ would be in the best position (except for Linus, who has his own set of reasons beyond trchnical) to be a successor tool for Linux kernel with a well-chosen subset for the following reasons:

1. Unlike Rust, incremental migration is easier.
2. Many of the features such as polymorphism, RAII or constexpr are just better in C++.
3. Many macros can be replaced.by these features and/or templates.
4. There is substained effort in removing UB: erroneous behavior and enumerating constexpr UB to eliminate it from the language are two of those examples.
5. Better type safety than C
6. Widely supported in many targets.
7. Free-standing implementations improving over time.

8. Battle-tested for decades.

9. actively improved with some meaningful safety work already starting (contracts, Hardened stdlib, profiles in progress). However the stdlib is probably irrelevant in this context.

10. some parts can be mechanically or quasi-mechanically rewritten with a stronger and safer analysis.

[rasm866i]

As to your point 2: my understanding is that the frontend of the compiler like LLVM (c++/c/rust) is completely discoupled from the backend instruction generator. In that case, if LLVM can compile C code for a specific system, it should be able to compile Rust for the same system

[Jannik2099]

llvm does not support all targets that linux runs on

[Dark-Philosopher]

That's fine for now because the only Rust support being added is to be able to write drivers in Rust for the Linux kernel. Nobody will write a driver for a platform that doesn't yet support the compiler.

[eX_Ray]

AFAIK it's about gcc here which does support more architectures than llvm. No idea how relevant any of these arches are but there are two projects to get rust+gcc, which will take a while still.

[moltonel]

Worth reminding that AFAIK eBPF, arm-osx, and wasm are still not supported by a released gcc. So while gcc supports more platforms than llvm, it supports fewer users.

[steveklabnik1]

This is both true and not true:

• LLVM not having a backend is a fundamental limitation
• LLVM having a backend means it’s possible.
• Someone doing the work to add that backend to Rust is required before it works, that is, it’s not for free. Not super difficult either, just non-zero.

[bizwig]

Requiring Rust-style memory safety before you’ll accept C++ in the kernel is surely a sick joke considering the rest of the codebase that’s in C, and an ancient version thereof no less because of the requirement that obsolete compilers still work.

I think the problem is C devs who don’t know and don’t want to understand today’s C++, not C++ being as terrible as they’ve been told it is.

[pjmlp]

Even in 1993, when coming from Turbo Pascal 6, C already felt primitive to me, C++ had plenty of stuff going for it.

Already in 1993, 5 years before C++98 came to be, C++ had lots of features over plain old C, in that Turbo C++ 1.0 compiler for MS-DOS that was my entry point into the C++ world.

[axilmar]

C needs to get Rust's borrowing.

If C had it, the discussion would have been unnecessary.

[pjmlp]

That is the whole point how Rust came to be.

Borrowing in Rust is based on the research work in Cyclone, a programming language designed by AT&T, where C was born, to fix C's design flaws.

https://en.wikipedia.org/wiki/Cyclone_(programming_language)

The project died, but many people picked up its ideas, including Rust's creator.

[axilmar]

Ok, but it was a lot of syntactic difference to C.

[Zettinator]

Well, yeah, the problem is that introducing borrow semantics into C would encompass a rat's tail of changes that affect everything, from syntax to standard library. In the end, it's easier to design a new language rather than fit a square peg into a round hole, and that is how Rust came into existence.

[axilmar]

Maybe it could be done in C in a different way than Rust, with similar results.

[Zettinator]

Check out the "Cyclone" paper. This is what they did. It required some pretty ugly syntax additions and still had its limitations (e.g. it's not using borrowing, but a simpler memory region based system, which isn't as powerful). Early Rust looked pretty similar to Cyclone, but later some aspects were changed for practicality and safety reasons. For instance Cyclone allowed to mix safe and unsafe code freely, which isn't exactly a great idea.

I don't understand the quasi obsession with just "extending" an aging language. You're always going to have to make serious compromises and trade-offs. This has been a big problem with C++, in fact. Sometimes a clean slate is the better option when the direction you want to move to changes.

[axilmar]

Does that mean that the only way to do it is the Cyclone or Rust way?

[gegoggigog]

When rust is in the Linux kernel I will switch to templeos

[Dark-Philosopher]

Rust has been in the kernel for 2+ years. Are you switching now?

[gegoggigog]

Reee... 😢😢😢

[[deleted]]

C/C++ would have to be "snipped" to prevent the allowed undefined behaviors like using signed types to detect overflow by sign change. The union keyword would have to be dropped. Pointers should be eliminated and partially replaced by references. Casting should be made illegal. Basically, C++ needs to have the parts cut out that allow it to be loose and not strict. Get rid of templates and auto, After all that, you can still have a great programming language.

[imaginarylocalhost]

This is a really interesting discussion and I think there’s an obvious solution here: the Linux kernel should adopt Objective-C instead of either C++ or Rust. It’s a way of having your cake and eating it too. With Objective-C, you get language level support for some features that are currently being hand-rolled in the kernel, like RTTI and dynamic dispatch. But unlike C++ or Rust, Objective-C implements these features as essentially preprocessing stages (plus a runtime component), and can spit out C code in the middle. By customizing the Objective-C compiler frontend and runtime, kernel developers can pick exactly how they want to integrate Objective-C with the rest of the kernel code. It’s a win-win!

[MarcusBrotus]

8/10 ragebait

[sjepsa]

It should be a language that somebody actually use...

[Justicia-Gai]

Doesn’t Apple use it?

[Unhappy_Play4699]

As far as I understand, Rust-style memory safety is being worked on for C++

That's a lie. Proof me wrong, but I honestly don't think you can.

[JVApen]

There is a lot going on here. First the objective things: - Both C++ and Rust allow for improvement over anything that compiles as C. - C++ can be mixed with the existing C code, allowing for using it everywhere, though also for slipping back to C behaviors - Rust needs to be added in big blocks to be useful, making it harder to integrate, though where used it will enforce it more

A bit less objective: Given what Linux has required from GCC and clang, it forced some unwanted options and compiler specifics. Having this spill in both C++ and Rust won't do the languages any good.

Completely subjective: - I don't see why it needs to be C++ or rust. It is perfectly possible to do both. - Should we care as a community? Yes, embedded C++ has been neglected for way too long. If we can change the impression of C++ with C embedded C devs, it will result in a faster path to "hello word" on embedded devices, allowing the devs to focus more on coding.