stop

writing

code

in

rust

the rust compiler is a fucking joke and nigh on impossible to bootstrap (because the idiots made it self-hosting instead of doing the responsible thing and writing it in C++), especially on non x86 systems.

like, look at this shit https://guix.gnu.org/blog/2018/bootstrapping-rust/

@velartrill
They use C++ impl to bootstrap it: https://github.com/thepowersgang/mrustc Rust needs more impls like other langs have. Writing "reference" impl in not itself would be hypocrisy 😃

@brombek > Writing "reference" impl in not itself would be hypocrisy

self-hosting a language has no upsides and many, many grave downsides. there is no good reason to do it, ever, period

@velartrill
Why are most languages self hosted then? C compilers are also self hosted. What are the downsides apart from secure bootstrapping needing another impl?

@brombek C compilers are self hosted because nobody has the discipline to maintain a proper bootstrap chain. and we've been saddled with a miserable "low-level" language in the first place that is not amenable to tidy BS chains.

other languages are selfhosted literally just because it's the norm. it's half cargo-cultism, half a nerd bragging point; almost every single language designer is just longing for the day he can dump all of his work and start the compiler over from scratch. none of them have coherent reasons for doing it.

> What are the downsides apart from secure bootstrapping needing another impl?

formally this is incorrect. the downside is that bootstrapping becomes *impossible,* at least without using an older, non-self-hosted version of the compiler. if you're using a different impl, that's not bootstrapping, it's just compiling. also, compiler devs never seem to care about bootstrapping, and just leave it to the poor packagers to figure out how to get their garbage running.

nitpicking aside, the downsides are vast. read Reflections on Trusting Trust, for one. but aside from actual malicious behavior, it means errors can accumulate over time, the behavior of the compiler can become more and more unpredictable as the detritus of compilation cycles grows and grows, difficult or impossible to find, let alone eliminate. increasingly it's a magic black box.

while this may be less of a problem using llvm, because that introduces an intermediate layer that can be used to sidestep the issue, in many cases self-hosting makes porting the compiler to new architectures transcendentally difficult. look into the horrorshow of getting Rust working on non-x86-based arches -- last i heard, there was just no way to do it, except maybe for arm.

(there are many other downsides but my head hurts, i'm tired, and those are the only ones that come to mind rn.)

and all this in turn for nothing. literally no benefits to be gained.

@velartrill
I get that there are theoretical concerns. The fact that "\n" value is nowhere to be found in rustc source is concerning. But as you noted, rustc is generating LLVM IR and not binary directly so you can inspect it there. Also you just need one other capable impl in already portable language to break the chain (even if you don't call it bootstrapping any more).

@velartrill
I guess having X written in X helps with development as you only need to know one language very well to develop it (less cognitive load?). And any advancement in your language reinforces your ability to further develop it. Rust was created to address problems with C++. Also first compiler was created in ML for a reason.

For what I know portability issues are mostly to do with LLVM missing support... if you have any links, I would like to learn more.

@velartrill
According to this https://doc.rust-lang.org/nightly/rustc/platform-support.html
the compiler runs on MIPS, PowerPC, RISC-V, SPARK and some other architectures.