What Rust needs is an alternative, gcc-based implementation similar to gccgo.

This will solve the problem immediately and allow Rust to be used on a much greater variety of targets, including obscure targets such as Tricore which are used in the automotive sector.

Only if Rust code runs everywhere, it will also be deployed everywhere.

Rust is on LLVM for a reason: implementing new languages on top of GCC is hard. It seems much more reasonable for unusual architectures to contribute to LLVM. If companies want to sell their own architecture, they should provide the support themselves, rather completely relying on free contributions from the OSS community.

Yes, you and I have spoken about this a few times over the years :) Glad to see the m68k work is still ongoing.

I too am pro getting Rust into gcc. We'll see how the effort goes.

And the moment that exists most of the issues the author currently ascribes to C will also be true for Rust.

True, but most Rust zealots (including me, though I'm reformed) haven't contributed anything to LLVM.

Most Rust developers aren't Rust zealots. It's largely people who are new to the language, I think.

The original person said "evangelists" and then slid into "zealotry." And I find a lot of anti-Rust folks seem to think anyone who likes Rust is a "zealot." YMMV.

I think that this is just a hard conversation to have, with a ton of different groups who all want different things, and have different incentives.

But it is. Unlike C/C++, Rust does not have undefined signed integer overflow or strict aliasing rules. Furthermore, you can do a few more things with pointers that are undefined in C/C++ (e.g., implementing offsetof the naïve way in C/C++ is undefined behavior, but would not be in Rust [assuming you use raw references, which are still in the process of being added]).

In general, there's a slice of behavior that's undefined behavior in C/C++ that isn't undefined behavior in Rust, and for people who want C to really be "portable assembly," Rust is arguably a slightly better choice as a result of being less likely to accidentally trip up on undefined behavior.

Unsafe Rust is harder to predict the behaviour of than C – at least, when you're doing completely off the wall stuff like re-using the stack in two threads. You can keep it contained, though, and so long as your unsafe Rust is keeping the language's invariants, the code is safe; therefore, you know where to start looking when there's trouble to be found.

I think it depends on what you're trying to do.