Joke, enterprise edition..

That was also the title of the HN post, before it was changed.

IIRC, it was not about Rust vs. C, but a commotion rooted from patch quality and not pushing people around about things.

Linux Kernel team has this habit of a forceful pushback which breaks souls and hearts when prodded too much.

Looks like Hector has deleted his Mastodon account, so I can't look back what he said exactly.

Oh, I still have the relevant tab open. It's about code quality: https://news.ycombinator.com/item?id=43043312

What they mean is that the Linux kernel has a long-standing policy to keep the whole kernel compilable on every commit, so any commit that changes an internal API must also fix up _all_ the places where that internal API is used.

While Rust in the kernel was experimental, this rule was relaxed somewhat to avoid introducing a barrier for programmers who didn't know Rust, so their work could proceed unimpeded while the experiment ran. In other words, the Rust code was allowed to be temporarily broken while the Rust maintainers fixed up uses of APIs that were changed in C code.

There is, I understand, an expectation that if you do make breaking changes to kernel APIs, you fix the callers of such APIs. Which has been a point of contention, that if a maintainer doesn't know Rust, how would they fix Rust users of an API?

The Rust for Linux folks have offered that they would fix up such changes, at least during the experimental period. I guess what this arrangement looks like long term will be discussed ~now.

And more specifically which ones that anyone would use a new kernel on?

Drivers are interesting from a safety perspective, because on systems without an IOMMU sending the wrong command to devices can potentially overwrite most of RAM. For example, if the safe wrappers let you write arbitrary data to a PCIe network card’s registers you could retarget a receive queue to the middle of a kernel memory page.

Is that all it is?

Can you expand on bitfields? There’s crates that implement bitfield structs via macros so while not being baked into the language I’m not sure what in practice Rust isn’t able to do on that front.

That first sentence though. Bitfields and ABI alongside each other.

Bitfield packing rules get pretty wild. Sure the user facing API in the language is convenient, but the ABI it produces is terrible (particularly in evolution).

I'm genuinely surprised that usize <=> pointer convertibility exists. Even Go has different types for pointer-width integers (uintptr) and sizes of things (int/uint). I can only guess that Rust's choice was seen as a harmless simplification at the time. Is it something that can be fixed with editions? My guess is no, or at least not easily.

In what architecture are those types different? Is there a good reason for it there architecturally, or is it just a toolchain idiosyncrasy in terms of how it's exposed (like LP64 vs. LLP64 etc.)?

Also you can't do self-referential strutcs.

Double-linked lists are also pain to implement, and they're are heavily used in kernel.

I agree with you for the most part, but it's worth noting that those standards can expose a C API/ABI while being primarily implemented in and/or used by non-C languages. I think we're a long way away from that, but there's no inherent reason why C would be a going concern for these in the Glorious RIIR Future:tm:.

Given Zig's approach to safety, you can get the same in C with static and runtime analysis tools, that many devs keep ignoring.

Already setting the proper defaults on a Makefile would get many people half way there, without changing to language yet to be 1.0, and no use-after-free story.

it is not straightforward in rust because the linked list is inherently tricky to implement correctly. Rust makes that very apparent (and, yeah, a bit too apparent).

I know, a linked list is not exactly super complex and rust makes that a bit tough. But the realisation one must have is this: building a linked list will break some key assumptions about memory safety, so trying to force that into rust is just not gonna make it.

Problem is I guess that for several of us, we have forgotten about memory safety and it's a bit painful to have that remembered to us by a compiler :-)

what is an intrusive data structure?

Or just build a tested unsafe implementation as a library. For example the Linked List in the standard library.

https://doc.rust-lang.org/src/alloc/collections/linked_list....

There is a set of languages which are essentially required to be available on any viable system. At present, these are probably C, C++, Perl, Python, Java, and Bash (with a degree of asterisks on the last two). Rust I don't think has made it through that door yet, but on current trends, it's at the threshold and will almost certainly step through. Leaving this set of mandatory languages is difficult (I think Fortran, and BASIC-with-an-asterisk, are the only languages to really have done so), and Perl is the only one I would risk money on departing in my lifetime.

I do firmly expect that we're less than a decade out from seeing some reference algorithm be implemented in Rust rather than C, probably a cryptographic algorithm or a media codec. Although you might argue that the egg library for e-graphs already qualifies.

What other newfangled alternative to C was ever adopted in the Linux kernel?

I have no doubt C will be around for a long time, but I think Rust also has a lot of staying power and won’t soon be replaced.

As mentioned in another thread, POSIX requires the presence of a C compiler,

https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c...

I can’t think of many real world production systems which don’t have a rust target. Also I’m hopeful the GCC backend for rustc makes some progress and can become an option for the more esoteric ones

> very slow compilation times

That isn't always the case. Slow compilations are usually because of procedural macros and/or heavy use of generics. And even then compile times are often comparable to languages like typescript and scala.

> My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.

if only due to the Lindy Effect

https://en.wikipedia.org/wiki/Lindy_effect

> Every system under the Sun has a C compiler... My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.

This is still the worst possible argument for C. If C persists in places no one uses, then who cares?

Doesn’t rustc emit LLVM IR? Are there a lot of systems that LLVM doesn’t support?

I don't know I tend to either come across new tools written in Rust, JavaScript or Python but relatively low amount of C. The times I see some "cargo install xyz" in a git repo of some new tool is definitely noticeable.

I'm a bit wary if this is hiding an agist sentiment, though. I doubt most Rust developers were 'born into' the language, but instead adopted it on top of existing experience in other languages.

> Obviously not

Is it obvious? I haven't heard of new projects in non-memory-safe languages lately, and I would think they would struggle to attract contributors.

It’s okay to enjoy driving an outdated and dangerous car for the thrill because it makes pleasing noise, as long as you don’t annoy too much other people with it.

> I prefer debugging C

I prefer not having to debug... I think most people would agree with that.

That's a rather pessimistic take compared to what's actually happening. What you say should apply to the big players like Amazon, Google, Microsoft, etc the most, because they arguably have massive C codebases. Yet, they're also some of the most enthusiastic adopters and promoters of Rust. A lot of other adopters also have legacy C codebases.

I'm not trying to hype up Rust or disparage C. I learned C first and then Rust, even before Rust 1.0 was released. And I have an idea why Rust finds acceptance, which is also what some of these companies have officially mentioned.

C is a nice little language that's easy to learn and understand. But the price you pay for it is in large applications where you have to handle resources like heap allocations. C doesn't offer any help there when you make such mistakes, though some linters might catch them. The reason for this, I think, is that C was developed in an era when they didn't have so much computing power to do such complicated analysis in the compiler.

People have been writing C for ages, but let me tell you - writing correct C is a whole different skill that's hard and takes ages to learn. If you think I'm saying this because I'm a bad programmer, then you would be wrong. I'm not a programmer at all (by qualification), but rather a hardware engineer who is more comfortable with assembly, registers, Bus, DRAM, DMA, etc. I still used to get widespread memory errors, because all it takes is a lapse in attention while coding. That strain is what Rust alleviates.

> It seems unlikely [Apple] would throw away that investment and move to Rust.

Apple has invested in Swift, another high level language with safety guarantees, which happens to have been created under Chris Lattner, otherwise known for creating LLVM. Swift's huge advantage over Rust, for application and system programming is that it supports an ABI [1] which Rust, famously, does not (other than falling back to a C ABI, which degrades its promises).

[1] for more on that topic, I recommend this excellent article: https://faultlore.com/blah/swift-abi/ Side note, the author of that article wrote Rust's std::collections API.

Also, Swift Embedded came out of the effort to eventually use Swift instead for such use cases at Apple.

Why? You can interact with C libraries from Rust just fine.

I disagree. Rust shines when you need perform "unsafe" operations. It forces programmers to be explicit and isolate their use of unsafe memory operations. This makes it significantly more feasible to keep track of invariants.

It is completely besides the point that you can also write "shit code" in Rust. Just because you are fed up with the "reimplement the world in Rust" culture does not mean that the tool itself is bad.

> Just like C++ never killed C, despite being perfect replacement for it

I think c++ didn't replace C because it is a bad language. It did not offer any improvements on the core advantages of C.

Rust however does. It's not perfect, but it has a substantially larger chance of "replacing" C, if that ever happens.

> No memory allocation means no Rust benefits.

This isn't really true; otherwise, there would be no reason for no_std to exist. Data race safety is independent of whether you allocate or not, lifetimes can be handy even for fixed-size arenas, you still get bounds checks, you still get other niceties like sum types/an expressive type system, etc.

> OS / Kernel - Nearly all of the relevant code is unsafe.

I think that characterization is rather exaggerated. IIRC the proportion of unsafe code in Redox OS is somewhere around 10%, and Steve Klabnik said that Oxide's Hubris has a similarly small proportion of unsafe code (~3% as of a year or two ago) [0]

> Browsers - Despite being born in a browser, Rust is unlikely to make any inroads.

Technically speaking, Rust already has. There has been Rust in Firefox for quite a while now, and Chromium has started allowing Rust for third-party components.

[0]: https://news.ycombinator.com/item?id=42312699

[1]: https://old.reddit.com/r/rust/comments/bhtuah/production_dep...

> Google has probably the largest C++ codebase in the world. Migrating to Rust would be so expensive that the board would squash it.

Google is transitioning large parts of Android to Rust and there is now first-party code in Chromium and V8 in Rust. I’m sure they’ll continue to write new C++ code for a good while, but they’ve made substantial investments to enable using Rust in these projects going forward.

Also, if you’re imagining the board of a multi-trillion dollar market cap company is making direct decisions about what languages get used, you may want to check what else in this list you are imagining.

> No memory allocation means no Rust benefits

There are memory safety issues that literally only apply to memory on the stack, like returning dangling pointers to local variables. Not touching the heap doesn't magically avoid all of the potential issues in C.

Rust is already making substantial inroads in browsers, especially for things like codecs. Chrome also recently replaced FreeType with Skrifa (Rust), and the JS Temporal API in V8 is implemented in Rust.

> Embedded - This will always be C. No memory allocation means no Rust benefits. Rust is also too complex for smaller systems to write compilers.

Modern embedded isn't your grandpa's embedded anymore. Modern embedded chips have multiple KiB of ram, some even above 1MiB and have been like that for almost a decade (look at ESP32 for instance). I once worked on embedded projects based on ESP32 that used full C++, with allocators, exceptions, ... using SPI RAM and worked great. There's a fantastic port of ESP-IDF on Rust that Espressif themselves is maintaining nowadays, too.

> No memory allocation means no Rust benefits.

Memory safety applies to all memory. Not just heap allocated memory.

This is a strange claim because it's so obviously false. Was this comment supposed to be satire and I just missed it?

Anyway, Rust has benefits beyond memory safety.

> Rust is also too complex for smaller systems to write compilers.

Rust uses LLVM as the compiler backend.

There are already a lot of embedded targets for Rust and a growing number of libraries. Some vendors have started adopting it with first-class support. Again, it's weird to make this claim.

> Nearly all of the relevant code is unsafe. There aren't many real benefits.

Unsafe sections do not make the entire usage of Rust unsafe. That's a common misconception from people who don't know much about Rust, but it's not like the unsafe keyword instantly obliterates any Rust advantages, or even all of its safety guarantees.

It's also strange to see this claim under an article about the kernel developers choosing to move forward with Rust.

> High Frequency Traders - They would care about the standard library except they are moving on from C++ to VHDL for their time-sensitive stuff. I would bet they move to a garbage-collected language for everything else, either Java or Go.

C++ and VHDL aren't interchangeable. They serve different purposes for different layers of the system. They aren't moving everything to FPGAs.

Betting on a garbage collected language is strange. Tail latencies matter a lot.

This entire comment is so weird and misinformed that I had to re-read it to make sure it wasn't satire or something.

    > Rust is also too complex for smaller systems to write compilers.

> The true future of "safe" software is already here, JavaScript.

only in interpreter mode.

Rust isn't that complex unless your pulling in magical macro libraries or dealing with things like pin and that stuff,which you really don't need to.

It's like saying python is complex becasue you have metaclasses, but you'll never need to reach for them.

Besides supply chain attacks, what could go wrong ? /s

https://rust-for-linux.com/unstable-features#unstable-featur...

Nah, they just smile when they see LLVM and GCC on Rust build dependencies. :)

He didn't intend it as a joke and his intent matches the op's title revision request: https://lwn.net/Articles/1049840/

> on this rare occasion couldn't resist the joke

It was unintentional as per author

> Ouch. That is what I get for pushing something out during a meeting, I guess. That was not my point; the experiment is done, and it was a success. I meant no more than that.

Fair. But there’s even an additional difference between snarky clickbait and “giving the exact opposite impression of the truth in a headline” ;)

Hacker news generally removes Clickbait titles regardless of the provenance

Guidelines say fine to editorialize in these cases.

> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.

https://news.ycombinator.com/newsguidelines.html

I think on HN, people waste too much time arguing about the phrasing of the headline, whether it is clickbait, etc. and not enough discussing the actual substance of the article.

I prefer improved titles. However, not in this case. It is rather irony, because LWN does not need click-bait.

Might as well just post it:

  The topic of the Rust experiment was just discussed at the annual Maintainers Summit. The consensus among the assembled developers is that Rust in the kernel is no longer experimental — it is now a core part of the kernel and is here to stay. So the "experimental" tag will be coming off. Congratulations are in order for all of the Rust-for-Linux team.

Perhaps, except it can have the reverse effect. I was surprised, disappointed, and then almost moved on without clicking the link or the discussion. I'm glad I clicked. But good titles don't mislead! (To be fair, this one didn't mislead, but it was confusing at best.)

freedom to shoot yourself in the foot?

how much?

I'm not on the Rust bandwagon, but statements like this make absolutely no sense.

A lot of software was written in C and C++ because they were the only option for decades. If you couldn't afford garbage collection and needed direct control of the hardware there wasn't much of a choice. Had their been "safer" alternatives, it's possible those would have been used instead.

It's only been in the last few years we've seen languages emerge that could actually replace C/C++ with projects like Rust, Zig and Odin. I'm not saying they will, or they should, but just that we actually have alternatives now.

That's not true when the topic is operating system kernels.

Most software development these days is JS/Typescript slop, popular doesn't equal better

People didn't use seatbelts before seatbelts were invented.

Most of the world uses other languages because they’re easier, not because they’re safer.

I've been working on Rust bindings for a C SDK recently, and the Rust wrapper code was far more complex than the C code it wrapped. I ended up ceding and getting reasonable wrappers by limiting how it can be used, instead of moddeling the C API's full capabilities. There are certainly sound, reasonable models of memory ownership that are difficult or impossible to express with Rust's ownership model.

Sure, a different model that was easy to model would have been picked if we were initially using Rust, but we were not, and the existing model in C is what we need to wrap. Also, a more Rust-friendly model would have incured higher memory costs.

I'm not a kernel developer myself, but I’m aware of the Tanenbaum/Torvalds debates in the early 90’s. My understanding is the primary reason Linus gave Tanenbaum for the monolithic design was performance, but I would think in 2025 this isn’t so relevant anymore.

And thanks for attempting to answer my question without snark or down voting. Usually HN is much better for discussion than this.

I agree it doesn’t magically eliminate bugs, and I don’t think rearchitecting the existing Linux kernel would be a fruitful direction regardless. That said, OS services split out into apps with more limited access can still provide a meaningful security barrier in the event of a crash. As it stands, a full kernel-space RCE is game over for a Linux system.

Even better, be like the Amish, and build your own as much as you can.

I'm guessing he means Rust voicing solidarity with Ukraine and sympathy with everyone affected by a conflict? It's hard to tell when people vaguepost. I guess wars of invasion/annexation are too controversial to oppose.

"Before going into the details of the new Rust release, we'd like to state that we stand in solidarity with the people of Ukraine and express our support for all people affected by this conflict."

I think they read the title but not the article and assumed Rust was being removed, and (rightfully, if that were true) opined that that was a shortsighted decision.

(Of course, that's not what's happening at all.)