Rust Patches For The Linux Kernel Updated A Fifth Time With New Features

[RahulSundaram]

Aarch64 is not "alternative". It's a mainstream Linux platform and it has tier1 Rust support so there's no problem whatsoever. In embedded systems, IoT etc yes there is still plenty of MIPS but I guess those won't be looking for brand new kernel features and functionalities developed in Rust, so the lack of first class Rust support shouldn't affect them too much either. Besides, as time goes those products will probably move to ARM too.

Yes I am aware it is not alternative now but it was one for Linux kernel up until recently, that's my point. What is brand new today in Rust will be routine code at some point and embedded systems running on alternative architectures may want to use it then. You may believe that everything in going to use ARM but I suspect that there will always be plenty of diversity in that space.

[jacob]

Yes I am aware it is not alternative now but it was one for Linux kernel up until recently, that's my point. What is brand new today in Rust will be routine code at some point and embedded systems running on alternative architectures may want to use it then. You may believe that everything in going to use ARM but I suspect that there will always be plenty of diversity in that space.

I'm not convinced that there will be plenty of diversity in embedded simply because of cost. Ultimately manufacturers of devices will prefer to rely on one architecture that is well known and supported by tools (or possibly two, with RISC-V), with a number of chip suppliers, rather than having to deal with dozens of different ISAs for essentially no benefit.

As for Aarch64 it was never alternative in Linux, to the contrary Linux support (not just the kernel, but also the toolchain etc) was an integral part of its development. Linux ran on it perfectly before the first production chips hit the market. Which kind of also makes my point above: these days no-one can hope to sell a CPU if Linux doesn't support it 100%, which is also why few people would risk putting another incompatible ISA on the market and having to incur all the burden and cost of porting the Linux ecosystem to it, rather than getting an ARM licence or going RISC-V and having it out of the box.

The execption to that can be ultra low-end microcontrollers (Arduino etc) which don't run a full-blown operating system anyway and Rust-in-Linux is not something they need to care about.

[RahulSundaram]

As for Aarch64 it was never alternative in Linux

We are still talking past each other on this. The architecture itself is relatively new, so there was plenty of years in the past people could have said who cares about anything besides x86 and power and stopped at that. Now we are adding Aarch64 into the mix, so we have to not tie ourselves up in current status quo because status quo keeps evolving.

[jacob]

We are still talking past each other on this. The architecture itself is relatively new, so there was plenty of years in the past people could have said who cares about anything besides x86 and power and stopped at that. Now we are adding Aarch64 into the mix, so we have to not tie ourselves up in current status quo because status quo keeps evolving.

We shouldn't be conflating alternative and new. It's still a comparatively new architecture but it had top notch Linux support from day 1 and a powerful momentum behind it. In fact, it has only ever been promoted as an architecture to run Linux on, so worries about it being sidelined due to a lack of Rust support or some other recent kernel feature were by definition moot. In my post I referred to real "alternatives" along the lines of SPARC, m68k, sh4, even MIPS: those are architectures that Linux can run on to varying degrees and some people are using it, but no-one has a compelling reason to use them for production applications, especially as far as Linux goes. So the fact that Rust doesn't support them (or at least not officially) shouldn't IMO hold Linux back.

[RahulSundaram]

We shouldn't be conflating alternative and new

I come at it from a distribution perspective where this is often used interchangeably, new architectures in Linux kernel are considered alternatives within a distribution till they get to a supported level within the distribution because distributions have to bootstrap a lot more than just the kernel.

... So the fact that Rust doesn't support them (or at least not officially) shouldn't IMO hold Linux back.

Your opinion will get trumped by Linux kernel developers who do considered other architectures as important. Good news is that Rust architecture is getting broader due to one or both of the GCC efforts. So in practice, this isn't an argument that is relevant. By the time, this effort is merged into mainline, the arch support in Rust will also have already improved so it's not going to hold anything back.

[sinepgib]

Good news is that Rust architecture is getting broader due to one or both of the GCC efforts.

I don't think that's the right path for Rust to get wider arch support tho. Considering GCC is not the easiest to work with, how (relatively) easy it is to add backends to LLVM and the fact rustc _is_ the reference, a GCC version will always be a step back compared to rustc. Not even taking into account possible mismatches in release cadence. I'm not sure there was a single scenario where GCC got second as far as free compilers get and got more success than the original one. It will probably always lead when it comes to C and C++ tho, but it did come first by a long time.

[karolherbst]

Rust was created as a replacement for C++, that's true, but in practice it sits somewhere between the two.

Rust > C > C++

and that's a fact

[kozman]

Seeing as how C is around 50 years old (1972) and Rust is just closing in on 12 years (July 2012), it's still young by comparison. But I don't think Rust sought to be a C or even C++ replacement from what I've followed of it over the years. IMHO, it's just another language whose authors sought to work around, solve or fix certain limitations in other languages. I know jack squat about programing but nearly 32 years in IT has taught me that things well programmed in C can really kick the pants off most other languages (not assembly or machine code). But Rust has it's limits presently, right? I feel like I once read an article or two that said writing drivers in Rust was a bitch as compared to C. The language just probably needs to evolve more. The types of computers and OSes that were around in 1972 (and even in the 80s/90s) are nothing like what we have in 2022. We'll just have to see how it evolves. I think history is littered with languages that have fallen out of favor.

[bachchain]

I feel like I once read an article or two that said writing drivers in Rust was a bitch as compared to C.

It can be annoying to make raw API calls from rust, but that's going to be true for any non-C language.

[CommunityMember]

In embedded systems, IoT etc yes there is still plenty of MIPS but I guess those won't be looking for brand new kernel features and functionalities developed in Rust, so the lack of first class Rust support shouldn't affect them too much either.

Given that drivers for new hardware, which are the current expected first users of new rust code, tend to be platform specific, those writing drivers for new hardware are going to know if rust is a viable choice for their hardware and platform. In practice, as you say, most new hardware devices are for the top few architectures, so this make it mostly just a timing game as more platforms with long term viability get additional support in the compilers.