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

[browseria]

I like Rust but it sucks that it doesn't yet have async functions in traits. 😭️
It also sucks that async is shattered islands with non-interoperable packages that depend on a specific async runtimes. 😭️

Regarding async in traits and interoperability, its coming: https://blog.rust-lang.org/inside-ru...c-in-2022.html

See also: https://blog.rust-lang.org/inside-ru...dmap-2024.html
https://blog.rust-lang.org/inside-ru...ions-2022.html

[erniv2]

Since you generally* don't read the assembly output, the compiler can turn your C code into the jumbo mumbo of hex data without going through the intermediate text representation. Which is also a bit of a lie because compilers use their own low level representation in many cases.

*Unless you specifically want to, in which case you pass a flag to the compiler so it outputs it.

Besides, there are sections of code where you can't avoid assembly. Some parts of the interrupt handling and setting of memory mappings are often done in assembly (tho I think GCC does provide extensions for most of it), and some performance sensitive code is written with explicit usage of SIMD extensions in plain assembly.

That is true usually you don´t notice whats realy happening because you just tell the frontend lets say gcc what it should do, you could get output for every stage if you want, precompile removes all the comments and pulls in header data, then the compile stage comes optimizing the maths and later if you set -march=native it picks an assembler code thats suitable for the used cpu, then comes the assembler output wich is depending on the cpu ofc. every time diffrent because every cpu has diffrent registers in the x86 case eax-edx and if you have mmx or sse it has xmm0-xmm7 and so on, then the assembler stage comes where it needs a assembler thats again compatible to your cpu and there it gets translated to machine code.

It´s quite complicated but every stage is needed to actually get runable binaries because you dont see it because the gcc frontend just outputs it to the tmp folder and removes it immideatly after doesn´t mean it is not happening.

Edit: also i doubt that handcrafting SIMD code nowdays realy beats the compiler, those guys codeing gcc/clang pull in cpu support all the time to get the best output, so why mess with it by putting in assembler in your code unless it´s realy needed like in cases where you have to access cpu registers for low level like stuff like the kernel that needs to deal with cpu features, kvm or in rare cases memory management, i doubt that handcrafting SIMD code for the userspace for video etc. has any effect at all.

[RahulSundaram]

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

You are starting from the conclusion and making assumptions to justify it. That itself is ideological. The pragmatic thing is to assume that people working on GCC-rs which is commercially funded btw are doing so because they have practical reasons to do it. Ideology doesn't pay the bills for a commercial organization.

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

Your main point is just a vacant claim. Unless there is a stable release, we absolutely cannot make any claims about the quality. The fact that some people in the Rust community don't understand why some people, vendors or distros may prefer GCC for entirely practical reasons or value multiple implementations, validating of specifications and instead of celebrating it end up talking crap about one of the projects on a regular basis is the reason why there is regular animosity seen here. It really is a failure on an otherwise welcoming group of people.

[moltonel]

Your main point is just a vacant claim. Unless there is a stable release, we absolutely cannot make any claims about the quality.

No, this is an informed prediction based on

• The huge difference in initial amount of work needed for the two approaches
• The ongoing work needed to stay on top of a rapidly evolving language
• The observation of all alternate language implementations (in gcc or otherwise) forever chasing the reference implementation
• The available manpower (rustc has more contributors to each of its 6-weekly releases than gcc over a longer period)
• The fact that most rust developers will not fancy improving gcc-rs because it is written in C++
• The archaic patch review and CI workflow of gcc compared to rust
• The network effect, which ensures that rustc will always have way more testers than gcc-rs
• The risk of gcc-rs funding ending before it gained a community able to keep it on top of rust evolutions
• The rust community's fear of an ecosystem split, which generates animosity toward gcc-rs

You can argue about how much of a problem each of these points is, but they all add up and all favor rustc with its gcc backend. Even if gcc-rs had a stable release today, these factors would continue to weigh the project down. It's not enough for gcc-rs to do a good job, it needs to do as good a job as rustc despite the odds.

The fact that some people in the Rust community don't understand why some people, vendors or distros may prefer GCC for entirely practical reasons or value multiple implementations, validating of specifications and instead of celebrating it end up talking crap about one of the projects on a regular basis is the reason why there is regular animosity seen here. It really is a failure on an otherwise welcoming group of people.

You misread me. I understand and even agree with many reasons to work on gcc-rs. I wish gcc-rs to be successful, for its eventual users and for Rust as a whole. But I do not think that gcc-rs can ever be good enough that people will want to use it for practical reasons. The reasons to choose gcc-rs over rustc.{llvm,gcc,cranelift} are ideological, like the license, trusting trust, or valuing multiple implementations.

[sinepgib]

You are starting from the conclusion and making assumptions to justify it. That itself is ideological. The pragmatic thing is to assume that people working on GCC-rs which is commercially funded btw are doing so because they have practical reasons to do it. Ideology doesn't pay the bills for a commercial organization.

No. That's how you work on assumptions and follow logic. I'm not claiming the reality of the situation is that, I'm pointing out that familiarity and all that plays when both solutions are more or less equivalent in quality, and that if that's not the case, then one choice would be the technical one and the other strictly ideological. IF.
If it happens to be the case, which I'm not saying it is, then the claim would be true.
Of course whoever is paying for it thinks it will be a reasonable solution tho, but it's beyond the point.

[RahulSundaram]

The reasons to choose gcc-rs over rustc.{llvm,gcc,cranelift} are ideological, like the license, trusting trust, or valuing multiple implementations.

If you view seminal papers like trusting trust as ideological, then it's an understanding of the word that I am not familiar with but I would like to see much more of that "ideology" and far less of animosity towards alternative free and open source software implementations.

No. That's how you work on assumptions and follow logic
..
Of course whoever is paying for it thinks it will be a reasonable solution tho, but it's beyond the point.

I don't know what practical insights we are gaining from these assumptions. I don't think that the fact that a commercial organization is paying for it is besides the point. It challenges the notion that it doesn't have practical value.

[moltonel]

If you view seminal papers like trusting trust as ideological, then it's an understanding of the word that I am not familiar with

Fair enough, I lumped it in the ideological category mainly to oppose it to the pragmatic/practical one, but it would fit better in some academic/theoretical category. But you're focusing on a small wrinkle of my argument and sidestepping the important ones : trusting trust and the other goals may be worth pursuing but have to be weighed against pragmatic goals where gcc-rs is likely to underperform. I think that gcc-rs is a cool project, but don't think it will ever be a compiler you should recommend for practical purposes.

I don't know what practical insights we are gaining from these assumptions. I don't think that the fact that a commercial organization is paying for it is besides the point. It challenges the notion that it doesn't have practical value.

Companies, just like individuals and organizations, can invest resources for ideological reasons or for a goal that they will fail to achieve. The fact that gcc-rs has paid full-time developers is not a strong argument that gcc-rs will achieve practical success (BTW, the main rustc_backend_gcc developer is also getting significant community sponsorship. Not a full salary, but arguably a stronger vote of confidence). The pragmatic goals of both projects is to compile to gcc-only targets (ignore insignificant llvm-only ones ) and see if we get the occasional better optimization. Rustc_backend_gcc is sure to achieve these goals, but for gcc-rs the prerequisite of not being noticeably bugyer than rustc and lagging in features are not a sure bet, to say the least.

[RahulSundaram]

Fair enough, I lumped it in the ideological category mainly to oppose it to the pragmatic/practical one, but it would fit better in some academic/theoretical category. But you're focusing on a small wrinkle of my argument and sidestepping the important ones : trusting trust and the other goals may be worth pursuing but have to be weighed against pragmatic goals

I disagree entirely with your categorization and view that trusting trust is merely academic or theoretical and if you don't see the practical value of entirely independent implementations, then it isn't a small wrinkle. We are not going to find common ground here.

Companies, just like individuals and organizations, can invest resources for ideological reasons

In the absence of a stronger evidentiary claim, the simplest explanation is the far more likelier one: It is more likely than not that commercial organizations are investing in something for commercial reasons.

[moltonel]

I disagree entirely with your categorization and view that trusting trust is merely academic or theoretical and if you don't see the practical value of entirely independent implementations, then it isn't a small wrinkle. We are not going to find common ground here.

I'm happy to look for common ground, if you can say what you categorize trusting trust as, instead of just rejecting my categorization. I only know that it is not a practical/pragmatic consideration, as no realistic attacks have ever been spotted in the wild and "nobody" actually run the checks themselves, they just trust that others have done so.

As for independent implementations, they clearly have value but there is a huge difference between languages that started as incompatible implementations and had to painfully arrive at a common spec (like C and C++ did) and languages with a reference implementation (like Rust or python), which have a single clear source of truth that alternate implementations strive to comply to. The value of those implementations is always on the backend, not the frontend. Python has a rich history of backends, and rust has llvm, gcc, and cranelift. If your practical goal is to define/document the rust language better and
get rid of inconsistencies, a new complex frontend is a stupidly inefficient way to go about it. The pragmatic solution is to work on the ferrocene spec, miri, or the various internal efforts. It's in this light that gcc-rs has little practical value as an independent implementation.

Again, for most people, the basic goal of gaining access to gcc's targets and optimizations dwarfs the other considerations like alternate implementation (categorized as "practical" or not) and it's clear that rustc_backend_gcc is the better project for this goal.

In the absence of a stronger evidentiary claim, the simplest explanation is the far more likelier one: It is more likely than not that commercial organizations are investing in something for commercial reasons.

I gave a big list of reasons and comparative evidence why gccrs is unlikely to achieve full success. I don't know how much clearer I can make this ? I don't want gccrs to fail, I'm just predicting it will. I did not check what Embecosm and Open Source Security inc's return on investment plan for sponsoring gccrs was, as it remains a poor predictor of what we might gain or lose from the gccrs effort.

[RahulSundaram]

I'm happy to look for common ground, if you can say what you categorize trusting trust as, instead of just rejecting my categorization

The issue here is demonstrable and one of the major ways to counteract that is to have a second fully independent compiler involved. There are many projects involved that are working towards mitigating these kind of attacks. If you want to discard all this work as merely theoretical, be my guest. Keep in mind, security exploits can lurk for decades without being widely known and people involved in this work certainly don't consider this as theoretical either.

I gave a big list of reasons and comparative evidence why gccrs is unlikely to achieve full success. I don't know how much clearer I can make this ? I don't want gccrs to fail, I'm just predicting it will. I did not check what Embecosm and Open Source Security inc's return on investment plan for sponsoring gccrs was, as it remains a poor predictor of what we might gain or lose from the gccrs effort.

None of your list of assumptions has anything to do with my basic point that multiple commercial organizations investing in an effort is unlikely to be ideological.