What does HackerNews think of mrustc?

Alternative rust compiler (re-implementation)

Language: C++

#17 in Compiler
> Maybe another memory safe language, but Rust has severe bootstrapping issues which is a hard sell for distros that care about source to binary transparency.

It is possible to bootstrap rustc from just GCC relatively easily, although it's a little bit time consuming.

You can use mrustc to bootstrap Rust 1.54: https://github.com/thepowersgang/mrustc

And from then you can go through each version all the way to the current 1.72. (Each new Rust version officially needs the previous one to compile.)

Ideally, what Guix would want is similar to what https://github.com/thepowersgang/mrustc/ does for Rust (a compiler, not written in Rust, for Rust).

So for Dylan, we'd like to have a compiler for Open Dylan, not written in Dylan. (it can also require multiple steps to get up to Open Dylan--that would be fine)

It's not in the interest of our users to use binary blob compilers for bootstrapping.

We would also unbundle LLVM, clang and the bdw gc and use the ones from Guix.

I wonder if a solution to your use case could look something like mrustc: https://github.com/thepowersgang/mrustc

The idea here would be to compile in a way that just assumes everything is correct and either crashes catastrophically or produces invalid output otherwise. But in doing so, it should allow at least slightly faster compilation.

You could even remove the need for this "fast and loose" compiler to do any type inference by shipping pre-processed source with all types resolved. However I don't know if this addition would fit your needs if, e.g., your goal is to be able to compile from any given commit rather than only official releases.

At very least it could be an interesting experiment to discover what tradeoffs are possible.

I wonder if mrustc [0] would be sufficient to retain the amalgamated build even if Rust were adopted. The regular Rust tool chain would be needed for development still, but if simply depending on the library the Rust components could be transpiled to C…

[0] - https://github.com/thepowersgang/mrustc

This alternative Rust compiler's intermediate representation is C code, which is then run through another compiler to produce the final output: https://github.com/thepowersgang/mrustc

Should its author generate Rust from Rust? Would it be better if Copilot produced object files or executables directly, or used eg. LLVM IR?

Since February, the mrustc project [0] has been capable of bootstrapping a relatively-recent Rust compiler from C++. (It currently takes another 8 Rust-to-Rust steps to reach the latest stable version.) I've personally tested it on my x86_64-linux-gnu machine, but I don't know how tough it would be to get it to support new targets.

[0] https://github.com/thepowersgang/mrustc

https://github.com/thepowersgang/mrustc is already providing that; it targets 1.54 right now, which is farther along than this project (though obviously that may not be always true in the future).
> (The same is not true for node.js, Go, or Rust, which as mentioned is one reason I don't use them for my site. If people stopped making binaries for them, I'd be lost.)

Thankfully, this no longer appears to be the case for Rust, thanks to mrustc [0], a compiler that can build a working Rust 1.54.0 toolchain (released 2021-06-29) from source. It requires only a C++14-compatible compiler and some other common tools; I've just verified that its build script works with no problems on my Ubuntu machine. To be safe, you'd want to specify exact dependency versions for everything (or better yet, vendor them locally), since the big crates all have different policies for when they break backward compatibility with older compiler versions.

[0] https://github.com/thepowersgang/mrustc

And then there's mrustc https://github.com/thepowersgang/mrustc , a Rust compiler written in C++, using LLVM.