
Mrustc: a Rust compiler written in C++ - mabynogy
https://github.com/thepowersgang/mrustc
======
kibwen
This was recently posted to /r/rust with the engagement of the author
(mutabah) if you'd like to ask questions or get involved. In particular here's
him answering why he started this project:
[https://www.reddit.com/r/rust/comments/718gbh/mrustc_alterna...](https://www.reddit.com/r/rust/comments/718gbh/mrustc_alternative_rust_compiler_written_in_c/dn90vo1/?context=10000)

One of the interesting things about this project is that because its initial
goal is to validate the reproducibility of the main Rust compiler it doesn't
actually need to implement a borrow checker, as the borrow checker strictly
rejects programs and has no role in code generation.

~~~
grok2
If you don't really need the borrow checker to compile Rust, can the original
Rust compiler have a mode where it doesn't do the borrow checking? That might
make it easier to ease into Rust, because right now, "fighting" the borrow-
checker is the hardest problem with learning Rust.

~~~
kibwen
Be careful not to underestimate the failure mode of trying to compile
arbitrary Rust code without the borrow checker. It appears that your goal is
to let people "ease into Rust" by trading compilation errors for runtime
segfaults, but it's just as likely that un-borrow-checked Rust code could
produce malformed LLVM IR that will cause totally unpredictable compile-time
failures in LLVM with indecipherably cryptic error messages.

~~~
grok2
That really wasn't my intention -- it mostly makes sense to use Rust for the
borrow checker. Instead my only intention was that it simplify the process of
learning Rust -- using all it's features (except the borrow checker), getting
a working program fast and have some easy wins when learning Rust without
stumbling constantly over the borrow checker. Maybe production mode could
always enable the borrow checker.

~~~
Lorkki
The need for the borrow checker is driven by Rust's chosen resource management
model. It sounds like what you really want is an optional mode with garbage
collection, in which case I recommend you check out F#.

~~~
vog
... or the "original", OCaml, from which Rust was heavily inspired.

~~~
sitkack
F# is a superset of OCaml, one can program OCaml in F#, sorta [1][2].

[1] [https://stackoverflow.com/questions/4239121/code-
compatibili...](https://stackoverflow.com/questions/4239121/code-
compatibility-between-ocaml-and-f)

[2] [https://stackoverflow.com/questions/179492/f-changes-to-
ocam...](https://stackoverflow.com/questions/179492/f-changes-to-ocaml)

~~~
thrasibule
F# is not a superset of OCaml. There are many things in OCaml that are not in
F#. The second link you pointed out lists them.

------
raimue
Maybe this compiler could help with bootstrapping the official rust compiler.
At the moment, it seems to be quite a mess for packagers. Rust is written in
Rust, but also needs cargo to build, which is also written in Rust. To break
this circular dependency chain, you need to have pre-compiled binaries first
in order to bootstrap the build process.

~~~
__david__
I don’t see why that’s an issue. Can you name a C compiler that distros use
that isn’t written in C?

~~~
raimue
C compilers are ubiquituous. Name a platform which does not have at least one
C compiler. Rust might come into such a position at some later time as well,
but until then at least a transitional solution besides cross-compiling would
make packaging easier and reproducible.

~~~
andrewflnr
Really, the solution is just to make cross compiling as easy as any other
kind. Compilation is basically a pure function, so by rights compilers with
different targets should be drop-in replacements of each other.

~~~
jjoonathan
> Compilation is basically a pure function

Sure, a pure function taking the universe as an argument.

~~~
alphaalpha101
No, a pure function taking the original source code as the only argument.

~~~
kibwen
Be careful, let's not forget the lesson of Ken Thompson's Reflections on
Trusting Trust. It's more accurate to say that compilation is a function that
takes two arguments: the source code, _and the compiler itself_ ; this is how
trusting-trust attacks propagate despite total absence from the source code.

~~~
weberc2
You're being pedantic, but your pedantry is incorrect, so allow me to be
pedantic in correcting you :p. The output of all pure functions depends on the
function and its inputs; this isn't more true for compilers than, say,
addition. The problem with Trusting Trust is that the function isn't
practically inspectable, not that the function is impure. A trusting trust
compiler is still pure.

~~~
falcolas
A functionally pure compiler would always provide the same output for the
given source code. The challenges in creating repeatable builds of highly
popular open source projects shows that the average compiler is anything but
functionally pure. The global state of the system running the compiler has a
huge impact on the output of the compiler.

~~~
weberc2
I agree, but that's irrelevant to the Trusting Trust topic.

------
fyrerise
Neat project. It looks like this was largely written by one person, and I'm
fairly in awe at anyone who can take a big project like a compiler this far
alone.

Isn't there a bit of cognitive dissonance in believing that Rust as a language
is an important idea (i.e. by the additional code safety and code
maintainability that it conveys), but then simultaneously making the effort to
rewrite the current Rust-implemented compiler in C++?

C++ is fast, but aside from a shared value around performance, it has fairly
little in common with the ideas that Rust is built on.

~~~
CUViper
By _not_ self-hosting in Rust, it should be easier to bootstrap on a new
target. C++ is ubiquitous -- what other language would you choose?

~~~
fyrerise
> _what other language would you choose?_

As far as I can tell the goal of the project isn't to target more platforms
(Rust targets quite a few by way of LLVM), so I don't think I'd choose any
other language, including C++.

Having a compiler and standard library written in the language that it
compiles has some huge benefits for increasing the pool of possible
contributors.

~~~
kibwen
_> As far as I can tell the goal of the project isn't to target more platforms
(Rust targets quite a few by way of LLVM)_

There appears to be an attempt to leverage this project to target ESP8266,
which AFAIK LLVM does not support: [https://github.com/emosenkis/esp-
rs](https://github.com/emosenkis/esp-rs)

~~~
kbenson
Interesting. Along with with your other comment about the borrow checker, I
guess you could develop using (or occasionally check against) the rustc
compiler for borrow checker correctness, and deploy using mrustc. That's
pretty cool.

------
steveklabnik
Lots of discussion and questions answered by the author on the Rust subreddit
the other day
[https://www.reddit.com/r/rust/comments/718gbh/mrustc_alterna...](https://www.reddit.com/r/rust/comments/718gbh/mrustc_alternative_rust_compiler_written_in_c/)

------
ndesaulniers
It's a major milestone for a compiled language to have it be self hosting.
Another is having a competing implementation of the compiler/runtime. That's
legit; cool project and kudos to the beautiful Rust ecosystem.

------
alexlarsson
IF the goal is bootstrapping another approach would be to use the llvm c
backend to generate a version of rustc and cargo that can be built by a c
compiler.

~~~
kiriakasis
IIRC the c backend for llvm was deprecated quite a while ago

------
phkahler
It may have been nice to build it on GCC instead of LLVM. First, the existing
Rust compiler uses LLVM so this won't be a fully independent implementation.
Second, it would provide GCC with a Rust front end.

------
topbanana
Curious why this wasn't written in Rust?

~~~
Ygg2
Rust compiler is already written in Rust, which means it can't be deployed to
some environments that C++ could.

This compiler in essence "bridges" the gap. Sorta.

