Rust in the kernel is no longer experimental

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.)?

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.

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.

> 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?

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.

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.

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

> 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...

> 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.

> 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.

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

I am not a compiler engineer, but I want to tease apart this statement. As I understand, the main Rust compiler uses LLVM framework which uses an intermediate language that is somewhat like platform independent assembly code. As long as you can write a lexer/parser to generate the intermediate language, there will be a separate backend to generate machine code from the intermediate language. In my (non-compiler-engineer) mind, separates the concern of front-end language (Rust) from target platform (embedded). Do you agree? Or do I misunderstand?

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.

> 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.

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

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 prefer improved titles. However, not in this case. It is rather irony, because LWN does not need click-bait.

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.

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.)

[dead]

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.

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.

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

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.)