Linus Torvalds: Rust For The Kernel Could Possibly Be Merged For Linux 5.20

[sinepgib]

You sort of are correct, but here we are arguing about semantics. Assembly and hexcode binary with executable code are 1-1 translatable to assembly unless we involve special tricks like packers or self modyfing code which doesn't really happen in most programs except malware and anti-RE programs.

If you talk about stuff like LLVM IR, those are higher level then assembly. Anyway most compilers allows outputting assembly that will be 1-1 to binary.

We are arguing semantics since the moment we are arguing whether this translation from C counts as the kernel "using assembly". It will obviously produce the bytecode, but in terms of maintainability that's irrelevant and in terms of toolchain unavoidable, so it makes no sense to count it as something the kernel uses side to side with C as if it were an implementation choice.
But regardless, as mentioned, the kernel uses assembly explicitly in some constrained places. Of the several existing variants.

And regarding allowing. Yes, "allow". That's the word. By default, they don't output assembly. When you build a kernel, it doesn't typically output assembly.

[evasb]

TL;DR: You should get excited about rustc_backend_gcc, not gcc-rs.

I'm not even a bit interested in this Frankenstein called rustc_backend_gcc, and I assure you that many distros are not either.

Also, looking at the effective adoption failure of gcc's other also-ran frontends for Go and D (both much simpler languages than Rust) should dampen your expectations about gcc-rs.

Well, I always compile against GCC-D and GCC-GO and never had a problem. It is just natural that people prefer to use the reference compilers, not GCC's fault.

[NobodyXu]

I'm not even a bit interested in this Frankenstein called rustc_backend_gcc, and I assure you that many distros are not either.

It's not Frankenstein.
It's simply a codegen backend for rustc, which take advantages of gcc.
There's nothing fancy about it.

Compared to gcc-rs, one which implements the entire rustc again in C++, it is significantly simpler and is more reliable, since it uses the battle tested code of rustc, and it also has up-to-date rust language implementation.

I honestly think gcc-rs duplicates a lot of effort put into rustc and would just have to chase after rustc forever.

[oleid]

[...] I assure you that many distros are not [interested in rustc_backend_gcc] either.

Why is that?

[moltonel]

Well, I always compile against GCC-D and GCC-GO and never had a problem. It is just natural that people prefer to use the reference compilers, not GCC's fault.

Searching online for "gccgo vs golang-go" (and other variations) finds a lot of gccgo bugs, some taking years to get fixed, some getting closed by downstream go projects with "I don't use gccgo, you're on your own". You'll also find a lot of benchmarks showing that gccgo is actually much slower than gc (despite taking longer to compile and the initial hope for better optimizations). Lastly, there's a handful of complaints that gccgo lags in features behind gc. You may not have a problem with gccgo, but it's clearly a sup-par compiler, whatever the reasons. Its only redeeming reason for existing is support of more targets. But the go ecosystem doesn't seem to care about anything beyond the server and associated workstations.

The same exercise for "dmd vs gdc vs ldc" yields too little info to be conclusive, as D just isn't popular enough. I couldn't find a package on my distro that supports or uses D (apart from gcc itself). The `announce` section on the d forum doesn't seem to have any user-facing apps. I'm curious what you use D for ? Are you just compiling gdc to prove a point ?

I'm not even a bit interested in this Frankenstein called rustc_backend_gcc, and I assure you that many distros are not either.

Where is this hatred coming from ? I'm guessing it's in reaction to the flak that gcc-rs is getting in many places, which would be an understandable reaction but not a good one. I'm not going to bash gcc-rs here, many people find it cool and you can too. But you should be able to like a project without hating its rival project.

As for distros, their main conern is usually to distribute bugfree software with minimal effort. Whichever way you look at it, rustc_backend_gcc is much more likely to provide that than gcc-rs, so pragmatically that's what distros will use on niche archs, unless they're anti-llvm pro-gnu idealists.

[sinepgib]

Where is this hatred coming from ? I'm guessing it's in reaction to the flak that gcc-rs is getting in many places, which would be an understandable reaction but not a good one. I'm not going to bash gcc-rs here, many people find it cool and you can too. But you should be able to like a project without hating its rival project.

As for distros, their main conern is usually to distribute bugfree software with minimal effort. Whichever way you look at it, rustc_backend_gcc is much more likely to provide that than gcc-rs, so pragmatically that's what distros will use on niche archs, unless they're anti-llvm pro-gnu idealists.

I was thinking. Wouldn't it make more sense to just make an LLVM frontend for GCC? Sure, build times will probably be longer, but it would also mean the effort is useful to more languages that may only target LLVM.

[RahulSundaram]

As for distros, their main conern is usually to distribute bugfree software with minimal effort. Whichever way you look at it, rustc_backend_gcc is much more likely to provide that than gcc-rs, so pragmatically that's what distros will use on niche archs, unless they're anti-llvm pro-gnu idealists.

There are good reasons for distros to use GCC over LLVM which is not limited to ideology. For instance, expertise and familiarity with GCC that they have developed over many years might be critical to be able to support code they have shipped for their customers. This is why having multiple options here is a good thing.

[sinepgib]

There are good reasons for distros to use GCC over LLVM which is not limited to ideology. For instance, expertise and familiarity with GCC that they have developed over many years might be critical to be able to support code they have shipped for their customers. This is why having multiple options here is a good thing.

But that's mostly for languages where GCC actually has good support, which is the contended claim. If half the Rust packages don't work with gcc-rs (big if, of course, it's for the sake of argument), the only likely reason to not use the working alternative would be ideological. Of course, for C, C++ and Fortran (and possibly many others)? Both are pretty much equivalent and preferring one over the other may be based on countless reasons, whatever the choice is in the end (and in fact most mainstream distros prefer GCC, probably out of habit since for a long time it was the only serious choice, and some because of the niche architecture support). But no sane distro will be using, e.g., gcc-go if that ends in countless bug reports compared to golang.

[moltonel]

I was thinking. Wouldn't it make more sense to just make an LLVM frontend for GCC?

(or the other way around) It's a suggestion that comes up every now and then, some conversion between both compiler's intermediate representation, but apparently it's harder and less universal than you'd hope.

[moltonel]

There are good reasons for distros to use GCC over LLVM which is not limited to ideology. For instance, expertise and familiarity with GCC that they have developed over many years might be critical to be able to support code they have shipped for their customers. This is why having multiple options here is a good thing.

Familiarity with gcc for its main languages does not mean familiarity with the more esoteric frontends. If all the troubleshooting guides are for rustc, it's going to be easier to use that. Also, at this stage, there can't be that many distros which are not familiar with llvm as well ? But the main point is that gcc-rs is inevitably going to be lower quality than rustc{,_codege_gcc} in the forseeable future, so gcc-rs would be an ideological choice, not a pragmatic one.

With all that said : yes, having choice is a good thing.