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

[sinepgib]

I don't know what practical insights we are gaining from these assumptions.

Not many practical insights can be extracted from it, of course, because it's entirely hypothetical. The only insight is that if it were to be true, the general behavior would be different that if it weren't, just that. The comparison between LLVM and GCC today applies in a general case where they're mostly equivalent in functionality. It wouldn't if, say, GCC's C support were still stuck at C89 when lots of projects are requiring C99 and C11 nowadays.

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.

It's besides the point precisely because I'm not proposing there is no practical value, not even that there wouldn't have had the implementations end up having dismal differences in quality
It's besides the point of the post you quoted in the context that the post was just a big if anyway. Maybe it would have been clear if I phrased it "beyond my point" instead.

[moltonel]

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.

All the work on trusting trust is valuable, interesting and important. But it doesn't solve a practical problem that users are facing today. A compromised compiler is far from being the weakest link in our current security, and it just isn't being exploited. I'm not dismissing the problem : a threat can be theoretical and still important to fix.

If compromised compilers ever become a real problem, it's not clear that gccrs is the best solution. Securing our supply chains and working on reproducible builds bootstrapped from mrustc seem like simpler and more auditable mitigations, which the community is already working on.

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.

I get your basic point, it's a decent heuristic. But you're pulling the conclusions much too far.

You're taking the fact that a company pays money for gccrs as a hint that gccrs will be a practical success. But the commercial entity can make mistakes : maybe it overestimated the benefit of the project, maybe it was blinded by an invalid dogma, maybe it underestimated the amount of work needed, etc. I once work on a project for about a year with a colleague before we and our company realized it wasn't a good idea. It happens.

The list I posted IMHO show that gccrs is very likely to fail at being a good alternate rust compiler in the long run, and that if people put money in the project hoping for practical returns, they made a bad decision. All the good practical outcomes of gccrs are better achieved by other means such as rustc_backend_gcc. What's left for gccrs are the ideological/theoretical/etc outcomes.

[RahulSundaram]

All the work on trusting trust is valuable, interesting and important. But it doesn't solve a practical problem that users are facing today. A compromised compiler is far from being the weakest link in our current security, and it just isn't being exploited

You have absolutely no way to demonstrate that this isn't getting exploited especially when you are depending only on a single implementation and people who are exploiting security issues have every incentive to keep it hidden. What you probably want to say is that there isn't a widely known instance of such exploit yet but that is a much more weaker claim than the one you made. If fixing the issue of a compromised compiler or associated enormous work being done to address this and other issues of reproducibility isn't "practical", we have very different definition of what practical means. I consider proactively fixing known attack vectors as very much practical regardless of the presence of public exploits of such vulnerabilities.

I get your basic point, it's a decent heuristic. But you're pulling the conclusions much too far.
You're taking the fact that a company pays money for gccrs as a hint that gccrs will be a practical success

Incorrect, you are pulling that conclusion too far. I never made any positive claims about success of gccrs.

[moltonel]

You have absolutely no way to demonstrate that this isn't getting exploited

Indeed, just like I have absolutely no proof that God doesn't exist. But I have plenty of examples of other attack vectors being exploited, and a sense of priorities. Again, all this preemptive work is important, but it doesn't solve an immediate problem.

Incorrect, you are pulling that conclusion too far. I never made any positive claims about success of gccrs.

It seemed to me that your arguments defending gccrs as practical implied a belief that it would succeed, sorry for misinterpreting. I could have been clearer with replies formulated as affirmations rather than rebutals, and focusing more on the main argument than the precise vocabulary. I'm obviously guilty of some of this too.

[RahulSundaram]

It seemed to me that your arguments defending gccrs as practical implied a belief that it would succeed, sorry for misinterpreting

It's fine, I have stated all my views explicitly and nothing is implied here. tldr: I consider it important to have alternative full implementation of major languages and it solves real problems which have increasingly become more important with the widespread issues associated supply chain verification and reproducibility. I would like the Rust community to completely drop all animosity against all free and open source implementations of the language be it mrust or gccrs. I make no claims about which implementations would succeed or fail or don't particularly care about that. I see from your replies that you don't consider the issues such as compiler attack vectors a priority or practical problem and we aren't going to agree on that, let's move on.

[NobodyXu]

I would like the Rust community to completely drop all animosity against all free and open source implementations of the language be it mrust or gccrs.

Both mrust and gccrs are being actively developed on, so I don't think the Rust community is against them.

It's true that most of the contributors to rust language and tooling would probably go for rustc, but that's because it's the reference implementation and is written in rust.

It's also true not all like gccrs as it duplicates effort, but we do not try to stop gccrs from being developed or deliberately make it hard to come up with an alternative implementation.

Thus, it is likely not a community.
If you think it needs more development, you can advertise it more in the rust community, though the people who are capable of doing C++ programming while being interested in compiler and have enough time is going to be niche.

[RahulSundaram]

Both mrust and gccrs are being actively developed on, so I don't think the Rust community is against them.

A certainly vocal group of Rust users certainly are as evidence by numerous posts in various places this topic is discussed. The projects are being developed despite this.

[NobodyXu]

A certainly vocal group of Rust users certainly are as evidence by numerous posts in various places this topic is discussed. The projects are being developed despite this.

As you have said, it is only part of the community and it is still being developed on, so I see no problem here.

The community of rust is fairly large, so you should expect to hear different voices and one that is against gcc-rs.

[moltonel]

tldr: I consider it important to have alternative full implementation of major languages and it solves real problems which have increasingly become more important with the widespread issues associated supply chain verification and reproducibility. [...] I see from your replies that you don't consider the issues such as compiler attack vectors a priority or practical problem and we aren't going to agree on that, let's move on.

That's fair enough, we disagree on how important it is. I do consider it important, but for example having Rust at all on more platforms is more urgent. Supply chain, reproducibility, bootstrapping have multiple solutions which can be explored in parallel and must be weighed for pros and cons. Full alternate implementations are just a mean to an end, make sure to keep the actual goals in mind.

I would like the Rust community to completely drop all animosity against all free and open source implementations of the language be it mrust or gccrs.

I have never seen any animosity towards mrustc, each update seems to receive a warm welcome. It is a comparatively simple compiler with the clear single purpose of bootstrapping rustc from C++, the community seems to agree on the goal and the method.

Like many in the community I've made peace with gccrs, but it's important to understand where the animosity will still come from in the foreseeable future. It's not about duplication of effort, or about dislike of GNU or C++. It's about the very real risk of making rust harder to work with, because of small compiler differences. If that was the price to pay for better platform support or reinvigorated development, the community would accept the risk. But rustc_backend_gcc brings platform support without the risk, and rustc development is very healthy. Rust developers are a perfectionist bunch, the bar for gccrs to be "good enough to not be harmful" is very high. There's a good reason for the animosity, it's unlikely to die down.

[sinepgib]

A certainly vocal group of Rust users certainly are as evidence by numerous posts in various places this topic is discussed. The projects are being developed despite this.

All communities will have vocal members disdaining other initiatives. That doesn't make them representative of the whole.