Google Wants To See Rust Code In The Linux Kernel, Contracts The Main Developer

[moltonel]

As long as there is no mainstream Rust frontend for GCC, Rust is a non-starter for me.

I develop a commercial C++ Win32 program that I cross-compile from Linux with MinGW (which has been rock solid) and I have yet to find a way to cross-compile Win32 programs with Clang/LLVM without pulling in vc headers and libs from a VS install on Windows. I also do occasional embedded development (arm-none-eabi) and there is no GCC alternative in this space.

Although in theory LLVMs modular nature and features make it well suited to cross-compilation, it's not close to there yet.

You probably want the gcc backend for rustc rather than the rust frontend for gcc.

But you seem to be confusing the means and the end ? If what you actually want is to (cross-)compile your software on your targets :

• LLVM works well natively on Windows, no hacky MinGW needed.
• Cross-compilation with rustc is much-more streamlined than cross-compiling C/C++ with LLVM or GCC, so you'll likely have less troubles with a Rust codebase than a C++ one.
• Rust (and therefore LLVM) does have support for various arm-unknown-*eabi

[ssokolow]

I think you'll find Rust currently supports basically every platform you care about (though they may use a different arch string than you expect, for example they use thumbv7em-none-eabihf for the ARM Cortex M4F).

As a pro-Rust person, I have to be fair and point to this. (An un-upstreamed fork of LLVM needed to target Espressif's Xtensa ISA, as used in the ESP8266 and ESP32 microcontrollers.)

...though, granted, the Rust community has stepped up to the plate on that front.

[moltonel]

Heh, a little bit of the latter.

I prefer that, to be honest

However it was a nod towards the fact that whilst Rust supports common platforms, that isn't always enough. What would you do if a client asks for a port of some software to a platform a Rust doesn't support? You have two choices, turn down the money or revert back to C or C++ and rewrite all your software.

The list of platforms you'll potentially support is a decision you make ahead of time, and Rust's current platform support is wide enough that it's very unlikely to be an issue. Even then, turning down an offer is not necessarily a bad thing: if that project is too much of a departure from your usual tech stack it might not be worth the extra time you'll need to spend on it. Better churn more projects that fit your stack well, especially if that stack lets you writer better software faster than the stack which supports every niche archs.

But Rust is still fairly immature. I am sure it will get better. Though I suppose it can never quite overtake C in terms of platforms.

YMMV, for some people Rust has been mature enough for years already, and some people will still claim it's immature 15 years from now. I'm really not worried about Rust reaching currently-alive platform parity with C: between the LLVM, Gcc, and Cranelift backends that should cover anything we reasonably need.

[ultimA]

YMMV, for some people Rust has been mature enough for years already, and some people will still claim it's immature 15 years from now. I'm really not worried about Rust reaching currently-alive platform parity with C: between the LLVM, Gcc, and Cranelift backends that should cover anything we reasonably need.

It is not really a question of people but a question of use-case. For kernel-development, it has been made pretty clear that Rust in its current form is very unsuitable because it sometimes crashes the caller (not due to a bug in Rust but as a desien-intent) instead of letting the error be handler by the caller. This is unacceptable in the kernel where you want to handle the error instead of generate an instant OS-crash. But I think there are people working on fixing this.

[oleid]

It is not really a question of people but a question of use-case. For kernel-development, it has been made pretty clear that Rust in its current form is very unsuitable because it sometimes crashes the caller (not due to a bug in Rust but as a desien-intent) instead of letting the error be handler by the caller. This is unacceptable in the kernel where you want to handle the error instead of generate an instant OS-crash. But I think there are people working on fixing this.

You are talking about the panic call? Two things:

1. it can be catched, if needed.
2. as they are not using the standard library, the kernel shouldn't be that much affected.

And yes, it is being worked on.

[Scellow]

sectarian behavior

[kpedersen]

Even then, turning down an offer is not necessarily a bad thing: if that project is too much of a departure from your usual tech stack it might not be worth the extra time you'll need to spend on it.

True enough. For example I have Unity3D firmly on the top of my middleware that I will not touch with a 50ft pole (Inefficient, error prone workflows consistently resulting in poor output). Though I guess I decided to specialize in C++ because it meant that I don't need to reject so many opportunities but honestly I suppose my point is moot because...

YMMV, for some people Rust has been mature enough for years already, and some people will still claim it's immature 15 years from now. I'm really not worried about Rust reaching currently-alive platform parity with C: between the LLVM, Gcc, and Cranelift backends that should cover anything we reasonably need.

Yeah, immature was probably the wrong word. Lets tone it down a little to "young". After all, the popularity of Rust has exploded so it has had many more man hours working on it in these recent years than many languages will receive in a lifetime. At this point it is likely more portable than those VM heavyweights like Java and certainly .NET. The fact that it is even being considered for (parts of) the Linux kernel where even C++ failed is actually quite positive.

[evasb]

I really don't know why some Rust people are so against a GCC frontend. Even Poettering is saying that GCC-RS is a must to systemd become rustified, and I think many projects are having the same position.

I see only positives in GCC-RS.

[ultimA]

You are talking about the panic call? Two things:

1. it can be catched, if needed.
2. as they are not using the standard library, the kernel shouldn't be that much affected.

And yes, it is being worked on.

I don't know if it's some code inlined by the compiler or if it's in the standard library. It also doesn't matter (except for the person fixing it), because I don't think it can be catched. Linus made it pretty clear this is a big problem and THE biggest showstopper for integrating Rust, so it is very unlikely there is a simple solution like "we can just catch it and handle the error then".

[phoenix_rizzen]

While I'm not necessarily opposed to this per se, it does feel like the motivation for this is more geared towards Rust being the hot new thing, and some opinionated/unverified "best-practice" dogma rather than based in actual technical merits.

I have no evidence to back this up, it's just my gut feeling.

I think if the devs at Google want to scratch a Rust itch, maybe they should be contributing to RedoxOS rather than introducing (arguably) unnecessary dependencies on building the Linux kernel. But hey, I think that battle is already lost with recent news that there's some Rust going into the kernel (or is it already in?).

Google's also using Rust for any new modules being added to / replacing existing modules in Fuchsia.