Hacker News Reader

Comment by ksec | Hacker News Reader

I have always thought Linus may not like Rust or at least not Pro-Rust, and the only reason Rust is marching inside the Kernel is most of his close lieutenant are extremely pro rust. So there is this Rust experiment.

But looking at all the recent responses it seems Rusted Linux is inevitable. He is Pro Rust.

View on HN

There was no reason to ever think otherwise. The experiment wouldn't have happened if he didn't want to try it and give it a certain amount of backing. He's been pretty vocal about his motivations.

https://www.youtube.com/watch?v=OvuEYtkOH88&t=6m07s

He certainly didn't have any trouble keeping C++ out.

Also in that thread is Greg KH: https://lore.kernel.org/rust-for-linux/2025021954-flaccid-pu...

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

Benefits C Vs. Rust are much more impactful than C Vs C++

Oh certainly. And many fewer potentially dangerous complex corner cases than C++ brings.

I'm pretty sure there is significant pressure from corporate sponsors in the Linux foundation to make Rust happen. That includes Google, Microsoft, AWS, ...

I think the pressures are from everywhere all the time. There's always a risk that something picks up enough steam to replace an OS even if it is a derivative or fork of the same OS. For C++ adoption, Linus gauged correctly that it's steam is limited and even directly taunting its supporters had low risk in a project that could challenge Linux because its set of choices over time has had many foot guns, where many developers would intentionally use what any user would consider a foot gun. As long as Linus didn't step in to define strong rules for how C++ would be used there was no likely challenger over any reasonable amount of time (for Linux/C). This is not true for rust.

The difference is that at least Google is actively deploying Rust-based Linux code in Android already.

And the big Linux foundation members have more influence than is publically known.

Linus was pretty clear about his views on working with vendors, etc, in his Autobiography so I'm not sure if/why there would be surprise.

Solaris, Java and C/C++ conpilers were all owned by Sun. I feel that is a situation without anyone even trying to maintain whatever separation some might expect from Linus.

That may actually make a little more sense.

"Rusted Linux is inevitable" for a good reason because Rust is objectively good language or better compared to C (Rust is designed what to fix flaws many language has)

The real reason being the longing for the 5 hour kernel compile of yore.

Well he DOES have a threadripper now.

And I'm sure the one thread used by the rust build will be blazing fast.

But why though? What about legacy systems, which may not have a rust toolchain? What about new architectures that may come up in the future?

Well there are a few ways to deal with this.

- Systems not supported by Rust can use older kernels. They can also -- at least for a while -- probably still use current kernel versions without enabling any Rust code. (And presumably no one is going to be writing any platform-specific code or drivers for a platform that doesn't have a Rust toolchain.)

- It will be a long time before building the kernel will actually require Rust. In that time, GCC's Rust frontend may become a viable alternative for building Linux+Rust. And any arch supported by GCC should be more-or-less easily targetable by that frontend.

- The final bit is just "tough shit". Keep up, or get left behind. That could be considered a shame, but that's life. Linux has dropped arch support in the past, and I'm sure it will do so in the future. But again, they can still use old kernels.

As for new architectures in the future, if they're popular enough to become a first-class citizen of the Linux kernel, they'll likely be popular enough for someone to write a LLVM backend for it and the glue in rustc to enable it. And if not, well... "tough shit".

Linus wouldnt accept rust unless it had technical merit.

If we never planned to evolve hardware and platforms, it of course would be senseless.

Thinking pragmatically, the legacy systems where there is no current rust toolchain most likely do not need the drivers and components that are being written in rust.

Unless you somehow want to run Apple M1 GPU drivers on a device that has no rust toolchain ... erm...

or you want to run a new experimental filesystem on a device that has no rust toolchain support?

The answer to the "new and emerging platforms" question is pretty much the same as before: sponsor someone to write the toolchain support. We've seen new platforms before and why shouldn't it follow the same pathway? Usually the c compiler is donated by the company or community that is investing into the new platform (for example the risc-v compiler support for gcc and llvm are both getting into maturity status, and the work is sponsored by the developer community, various non-profit[1][2] and for-profit members of the ecosystem as well as from the academic community.)

realistically speaking, it's very hard to come up with examples of the hypothetical.

[1] https://github.com/lowRISC/riscv-llvm

[2] https://lists.llvm.org/pipermail/llvm-dev/2016-August/103748...

I suspect gcc-rs will be in good working order for a few years before any kernel subsystems require a Rust compiler to build; if the legacy system can't run a recent GCC, why does it need a much-newer kernel? (e.g., how would it cope with the kernel requiring an additional GCC extension, bumping the minimum standard version of C, etc.)

I honestly suspect new architectures will be supported in LLVM before GCC nowadays; most companies are far more comfortable working with a non-GPL toolchain, and IMHO LLVM's internals are better-documented (though I've never added a new target).

> What about legacy systems, which may not have a rust toolchain?

Linux's attitude has always been either you keep up or you get dropped - see the lack of any stable driver API and the ruthless pruning of unmaintained drivers.

> What about new architectures that may come up in the future?

Who's to say they won't have a Rust compiler? Who's to say they will have a C one?

Linux also cant be built by any minimal c compiler for obscure arch, it requires many gcc extensions. Its only because llvm added them that its also can be compiled with llvm

> Linux's attitude has always been either you keep up or you get dropped

Gonna need a citation on that one. Drivers are removed when they don't have users anymore, and a user piping up is enough to keep the driver in the tree:

For example:

   > As suggested by both Greg and Jakub, let's remove the ones that look
   > are most likely to have no users left and also get in the way of the
   > wext cleanup. If anyone is still using any of these, we can revert the
   > driver removal individually.

https://lore.kernel.org/lkml/20231030071922.233080-1-glaubit...

Or the x32 platform removal proposal, which didn't happen against after some users showed up:

   > > > I'm seriously considering sending a patch to remove x32 support from
   > > > upstream Linux.  Here are some problems with it:
   > >
   > > Apparently the main real use case is for extreme benchmarking. It's
   > > the only use-case where the complexity of maintaining a whole
   > > development environment and distro is worth it, it seems. Apparently a
   > > number of Spec submissions have been done with the x32 model.
   > >
   > > I'm not opposed to trying to sunset the support, but let's see who complains..
   >
   > I'm just a single user. I do rely on it though, FWIW.
   > […snipped further discussion]

https://lore.kernel.org/lkml/CAPmeqMrVqJm4sqVgSLqJnmaVC5iakj...

Curious: what widely-used (Linux) legacy systems do not have a Rust toolchain?

In the end the question is whether you want to hold back progress for 99.9% of the users because there are still 200 people running Linux on an Amiga with m68k. I am pretty sure that the number of Linux on Apple Silicon users outnumbers m68k and some other legacy systems by at least an order of magnitude (if not more). (There are currently close to 50000 counted installs. [1])

[1] https://stats.asahilinux.org

I currently dont.

I do

There are enough of them that some (e.g. me) actually read this comment.

I think that'll become a question if/when rust starts to move closer to core parts of the kernel, as opposed to platform-specific driver code. It's already been considered for filesystems which could in theory run on those systems, and the project seems to be OK with the idea that it's just not supported on those platforms. But that's likely a long way off, after there's a significant body of optional rust code in the kernel, and the landscape may already be quite different at that point (both in terms of if those systems are still maintained, and in terms of the kind of targets rust can support, especially if the gcc backend matures)

You don't get to run legacy systems with rust based drivers. You were not going to do that anyhow, so what is the issue, really?

Those are the tradeoffs, and it seems to me that Linux doesn't have to run in everything under the Sun as Doom ports do, and there might be other kernels that are better suited to such cases.

You can compile Rust for Win98. They‘ll be fine.

The legacy systems are not very important. The new ones will be supported.

"But why though? What about legacy systems" their called legacy for a reason right

I'm sorry you cant hinder kernel development just because some random guy/corpo cant use your shit in obscure system, like how can that logic is apply to everything

if your shit is legacy then use legacy kernel

Uhhhhh IIRC rust uses llvm under the hood so ... Change the back end and you are good?

There are some platforms which linux supports that LLVM does not (and GCC does). There is quite a lot of effort in making a decent LLVM backend, and these older systems tend to have relatively few maintainers, so there may not be the resources to make it happen.

> There is quite a lot of effort in making a decent LLVM backend, and these older systems tend to have relatively few maintainers

Well, it also takes effort to be held back with outdated tools. Also, the LLVM backend doesn't have to be top-notch, just runnable. If they want to run legacy hardware they should be okay with running a legacy or taking the performance hit of a weaker LLVM back-end.

Realistically

At version 16[1], LLVM supports: * IA-32 * x86-64 * ARM * Qualcomm Hexagon * LoongArch * M68K * MIPS * PowerPC * SPARC * z/Architecture * XCore * others

in the past it had support for Cell and Alpha, but I'm sure that the old code could be revived if needed, so how many users are effected here? Lets not forget the Linux dropped Itanium support and I'm sure someone is still running that somewhere.

Looking through this list [2], what I see missing is Elbrus, PA-RISC, OpenRisc, and SuperH. So pretty niche stuff.

[1] https://en.wikipedia.org/wiki/LLVM#Backends

[2] https://en.wikipedia.org/wiki/List_of_Linux-supported_comput...

Then use the GCC backend. https://github.com/rust-lang/rustc_codegen_gcc

Aren't those already situations we use cross compiler for?

A cross compiler is just compiler backend for machine X running on machine Y. You still need the backend.

Reply on news.ycombinator.com