> I think he makes a good point about the fact that it's certainly possible the Rust code written today won't still compile in 10 years

It’s possible but unlikely. The Editions feature [1] has been specifically designed to provide longevity.

[1]: https://doc.rust-lang.org/edition-guide/editions/index.html

Section 3.16 ("Platform and target support") of the linked document is so inadequate for Linux kernel related questions, such as "what compilation targets will be supported by this Rust Edition in 10 years", that there is nothing to quote to show it's inadequate. It doesn't even tell what compilation targets are supported right now.

The canonical link for platform support is here: https://doc.rust-lang.org/stable/rustc/platform-support.html

There is no commitment to keeping the platforms in tier 1, 2 or 3 for any length of time or to provide advance warning before platforms are degraded, not to mention that the tier 1 list is vastly insufficient (Arm64, x86, x86_64).

Rustc is clearly meant to compile Rust applications and use for the Linux kernel, which from the point of view of this document would be narrower than tier 1, is highly experimental.

Where does Linux document how long platforms are guaranteed support? My understanding is there's not either.

(And yes, we'd love to expand the tier list. It's a chicken and egg situation. That being said, I work mostly in tier 2 and 3 targets, and they just vary a lot. The ones I work in work as good as tier 1 targets do. The path to moving forward is bright for many of these.)

> Rustc is clearly meant to compile Rust applications

I don't see what about this implies that at all. As a core team member and someone writing an embedded OS at work, I can assure you that we don't think of Rust as purely an application language.

Maybe I'm unfamiliar with Rust, but if you list OSX, Linux and Windows on identical processors as different platforms they are platforms for applications, not for an OS kernel that runs on "bare metal": it implies that support includes relying on OS provided system calls to manage processes, implement the standard library, etc.

Sure, the standard library on those targets depends on OS services. But you don’t have to use the standard library. Many people do write userspace programs in Rust, just like they do in C. That doesn’t mean that it’s only useful or intended for userspace, just like C.

It takes more work to port an entire standard library than to not.

unless you plan to run `rustc` as a kernelspace application, anything in tier 2 (`core`, `alloc`, maybe `std` all compile and likely pass tests) is sufficient

Personal pet peeve: new people who come into a project without any context and use their own idiosyncratic code style. :-)

I agree, but if it helps creating more and better drivers, it might be a good thing considering the lifetime of the target hardware matches Rust lifetime.