Hacker News Reader

Comment by monoideism | Hacker News Reader

Agreed. It would likely take a half-a-dozen full-time devs several years to fully re-implement Rust, if they're highly skilled.

A gcc rustc backend is the way to go, clearly. That company would have been better off paying for that.

View on HN

> That company would have been better off paying for that.

This is only the case if you assume their primary goal is to get a reimplementation as fast as possible. In my understanding that is not their primary goal. Their primary goal is to not require a Rust compiler in the build process. This means that the approach you suggest doesn't fit requirements.

"Their primary goal is to not require a Rust compiler in the build process"

Do you mean their goal is not to require `rustc` in the build process? Because I'm not sure how they're going to compile rust code without a rust compiler.

They wouldn’t need to compile Rust code, because said compiler would be implemented in C++. It would produce a Rust compiler, but would not require one to exist in order to do so.

mrustc for bootstrapping, rust_codegen_gcc (which doesn't seem like it would make stage1 much harder to compile) once the rest of the compiler has been brought up, isn't that the more realistic plan?

That's significantly more complex, and would still involve relying on a pre-built binary.

The goal for the dev is to be able to compile rust code in governmental code base. As all the static checking will still be done with rustc, it doesn't need to be a full compiler.

> As all the static checking will still be done with rustc, it doesn't need to be a full compiler.

So then this is just a backend?

If you're talking about gccrs, no, it's a full reimplementation. I think your parent is saying developers can use rustc (including its borrow checker) while iterating, then produce the release builds using gccrs from code that is known to borrow check.

Reply on news.ycombinator.com