It’s strange for me why anybody would reimplement a Rust compiler in C++ instead of Rust, but people are free to do what they want :)
There's a bunch of corporate/.gov envs that don't allow binaries to enter their system. All new code has to be compiled from source, on the target system (or at least on that side of the process firewall, it might be an airgapped cluster that can share code). They have C and C++ compilers that they've been compiling from source since the dawn of time, but they don't have a rust compiler. This gives them a mechanism to begin using rust within their process.
Being able to target a pretty recent version of Rust with a compiler written in C would be so, so useful for these purposes.
I would assume that on such compilation farms that these systems generally use, this could be done very quickly.
Perhaps there would be an interest for the Rustc team to provide a recursive automated setup that is capable of compiling the latest Rustc from OCaml, and finally from C as well since one must follow a similar process with OCaml.
Methinks that building this chain by trial and error is rather trivial compared to the actual work in building a compiler.
Typically, they are inversely correlated.
Since them they've bootstrapped this all the way to 1.50: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages...
The work done here is non trivial, this chain of versions are required for the final binary to be reproducible.
Indeed. Although it is being worked on, the whole bootstrap process of rustc is currently a major hassle, requiring to start from the oldest CaML versions of the compiler up to the most recent ones.
I hope there's some automated assistance for scanning inbound source code too. Imagine reviewing everything, line by line, millions of them.
I remember reading an interesting thought experiment that traced history that investigated what would happen if Dennis Ritchie had put malicious code in the first C compiler that was designed to detect whether the compiler compiled a compiler, and then copied the malicious code into it.
It concluded that tracing the history, that if this were to have happened, then GCC and Clang and many other programming languages would have said malicious code in their compilers that do not show up in the source code with none the wiser.
Before the B compiler written in B, there was a B compiler written in something else. I couldn't figure out what from that document.
Or would that not count as “compiling from source”?
I guess you didn't want to advertise the real reason of the project.
This takes very long and is error-prone, so having a compiler that can build even an intermediate version is already a big help.
You don't have a real language until there is a stable specification and multiple independent implementations. Until then it's just an experimental toy.
And people do see the pain here as a problem, that's why the project in this very thread exists. I think most in the Rust community see mrustc and the pressure that an independent implementation brings process wise as a very good thing for the language.
It should probably be still functional, or easily fixed if not.
That doesn't mean Python isn't useful! It is in fact a wildly successful tool that has spawned a large ecosystem of packages and a diverse group of users. But it unfortunately does not qualify as a true language, for it lacks the necessary ingredients: a formal specification of the language and more than one implementation of said specification.
This has a "I will cancel my subscription" letters to the editor feel, as if anyone cares :-)
I mean, there are pros and cons to any language and ecosystem. "I found some fault in bootstrapping approach and will condemn the whole language/effort for it" is a hardly a reasonable argument...
As if regular devs often have a need to bootstrap from scratch themselves...