Hacker News Reader

Comment by faitswulff | Hacker News Reader

I see, so it’s written in C++. Would it remain that way, though? AFAIK the LLVM Rust is, itself, written in Rust, right? I imagine that it would be a goal to do the same for gcc.

View on HN

There is absolutely no reason why the GCC front-end needs to be written in Rust. The reason the LLVM front-end was written in Rust initially was so they could immediately test and use new features in what was at the time also the largest program in Rust. Re-writing the GCC front-end in Rust would just prolong an already rather unfortunate bootstrap problem with the language and it should be strongly discouraged.

As it stands, the way to bootstrap the official Rust compiler from source with just a C/C++ compiler is a few options:

* Compile OCaml (implemented in C), use it to build the original Rust front-end in OCaml and then build each successive version of the language until you hit 1.49. This option is not fun.

* Compile mrustc, which is a C++ implemented compiler that supports Rust 1.29. Use that to build the actual Rust 1.29 and then iterate building your way all the way to 1.49. That is less bad, but still not fun.

* Compile the 1.49 compiler to WASM and run it via a C/C++ implemented runtime in order to compile itself on the target system. This would also mean packaging and distributing the WASM generated code, which some distributions would refuse. I also am not sure if it's even currently feasible, as I don't follow the WASM situation closely.

A compliant, independent C++ implementation that could be built in the ten minutes it takes to build GCC itself would be a very good thing to have and would be more friendly to distribution maintainers.

I don't see why a wasm blob would be any more palatable to maintainers than an executable.

Like I mentioned in my post, it wouldn't be for some depending how serious they take things. I'm well aware many would refuse generated artifacts, even compiled to source artifacts. For others not so strict, they may accept it since the WASM blob would be the same across targets, unlike an executable, so it lessens a burden as maintainers only have to generate it once for their distribution. It was never something I suggested the Rust maintainers provide a blob for, either.

Regardless, it was worth mentioning as a potential option. I am one of the handful of maintainers for an experimental distribution where packages are either compiled or interpreted from tarballs and this would be something we'd consider. I'd MUCH rather have the GCC front-end option, however. So far, we've simply not packaged Rust and have accepted that as dead-ending our Firefox package. This may potentially revive it.

> There is absolutely no reason why the GCC front-end needs to be written in Rust.

How about memory safety and fearless concurrency?

Not a requirement for a GCC front-end and certainly not worth sacrificing a potentially faster path to bootstrapping the official compiler implementation. You should be worried about the ease by which various systems can bootstrap and adopt the language, which is a mostly solved problem for C/C++ but not a given for Rust itself. Some maintainers will absolutely refuse bootstrapping off of binary artifacts compiled from other systems, others won't even accept 'compiled to C' artifacts.

Keeping a viable C++ implementation as part of GCC would be the smartest decision.

The Bootstrappable builds folks dislike binary artifacts so much they are implementing bootstrapping a full Linux system from only 512 bytes of machine code plus all the source code:

https://bootstrappable.org/ https://bootstrapping.miraheze.org/wiki/Main_Page

Who are these groups who are demanding such easy bootstrapping? OS or distro developers? Programmers working on embedded and/or safety critical systems?

I know OpenBSD avoids rust because of the bootstrapping issue, but they also avoid LLVM because of a licensing issue.

OpenBSD uses clang/llvm on most arches by now for the system compiler.

Uf. Brain fart. I meant that they avoid GCC because of licensing.

bootstrapping is important, but I believe that GCC already allows non-primary (i.e. optional) languages frontends to be written in other languages. The ADA front end is written in ADA for example.

A compiler front-end is pretty boring software in terms of memory safety. Lots of things that the front-end allocates are simply never freed.

Have you ever seen GCC crash with a SIGSEGV? I rarely did even when I used to be a GCC developer.

Indeed. Notoriously, a SEGV in gcc during compilation used to usually mean "your hardware is flaky": https://tldp.org/FAQ/sig11/html/index.html

That was before the invention of fuzzing.

There are still out-of-bounds concerns and chasing through NULL pointers. (Not arguing against gcc's quality or stability, just listing memory safety concerns that transcend memory deallocation)

I guess you could rewrite it in a language with no implementation at all if you are worried about purity.

No one is saying that rustc should be rewritten in C. They are saying that an alternative compiler front-end in an alternative language is sensible.

No one is saying that someone said rustc should be rewritten.

It could take the same approach as GDC and GNAT, by having the frontend written on the same language (D and Ada respectively), shared with other implementations using another set of backends.

Reply on news.ycombinator.com