Having multiple implementations is a sign of a healthy programming language. C++, Rust's primary competitor in this space has multiple implementations and all are used by somebody. In fact, if rust as a language cannot deal with multiple compilers (ecosystem doesn't allow it as you described by your crates.io) then I don't see how it can overtake C++.
Re:GCC Rust Monthly Report #9 August 2021
by myrrlyn on Tuesday August 31, 2021 @05:07PM
(#28373674)
> Having multiple implementations is a sign of a healthy programming language
this is frequently taken as axiomatic but there's no actual support for it in reality. there are plenty of healthy single-implementation languages (go, rust, scala, erlang) and plenty of unhealthy multi-implementation languages (c, d, sql, javascript) to go alongside the healthy/multi (python, ruby) and unhealthy/single (php, i guess, i don't care about this quadrant very much)
Re:GCC Rust Monthly Report #9 August 2021
by southerntofu on Tuesday August 31, 2021 @02:08PM
(#28371427)
> if rust as a language cannot deal with multiple compilers (ecosystem doesn't allow it as you described by your crates.io)
Why would that not be the case? crates.io is just a code repository like any other. You don't need crates.io to write/use Rust code, and crates.io has no specific requirement for a certain compiler.
It just so happens that currently only the main implementation of Rust language (rustc) can compile all of crates.io repository, but this could change in the future.
Every single time I had to do this, I opened a PR to the Rust reference with the fix. :shrug:
> That should never happen.
Sure, and the way this gets fixed is with documentation. GCC frontends have this same problem. I've had to read the GCC C++ frontend source code a million times already to figure out if it was standard compliant. When it wasn't, I sent a patch fixing it, instead of.... starting rewriting a new frontend from scratch.
Compared with GCC, the Rust frontend source code was almost every single time infinitely better documented. Many internal modules are actually intended to be read as documentation, and I do read the rendered compiler API docs every now and then when looking for something. The quality of GCC docs was... not great.
> C++ has only benefited from having multiple compilers.
C++ starting point was very different than Rust's.
> If you're afraid of fragmentation or Rust dying as a result of this, I can assure you that historically, the exact opposite takes place.
I'm not afraid, just curious about what value is in here.
I don't see why anyone would use GCC Rust, instead of the GCC backend, for anything. Most real-world Rust projects use 100s of crates.io dependencies. All real-word Rust projects I use, use nightly, and crates from crates.io that work on nightly. No idea how GCC Rust could achieve "daily" parity with Rust for anything practical. What's the strategy here?