Hacker News new | ask | show | jobs
by CUViper 3192 days ago
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?
4 comments

> 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.

> 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

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.
> Having a compiler and standard library written in the language that it compiles has some huge benefits for increasing the pool of possible contributors.

But this isn't the official compiler, this is someone's personal project?

> But this isn't the official compiler, this is someone's personal project?

True, but compilers are complicated machines and Rust is still changing at a fairly frantic rate.

The author seems to be doing quite a good job of development today, but if it has any hope of staying current, it probably needs to think about how to increase its bus factor (something happens like changing jobs, starting a family, or they just become interested in something else, and a single person suddenly has less time to contribute).

rust is changing, but in a backwards compatible way. That said the standard library aggressively makes use of new features, so the challenge isn't the language, but compiling libstd.
Could rustc have a way to output desugared code or code targeting a specific epoch with new features like generators expand to a backwards compatible form. This might allow for preprocessed source that could be compiled by something like mrustc even if it doesn't implement every single RFC?
That's sort of MIR, but we have no intentions of stabilizing it any time soon, if ever.
If bootstrapping/portability is the goal, probably C.
Conveniently there are already C++ compilers bootstrappable with C.
Any that are both open-source and C++11 compliant? Guess you can still build g++-4.6 with just C, then a newer g++ from that, but it's a bit of a pain.
If the goal is to break the dependency cycle, a higher level language like Python would make development much easier. C++ is powerful, but not as rapid to develop in.
Why the downvotes?

It's clearly easier to make a compiler in a higher level language (Python is just an example, but Lisps are suited to this kind of thing). For example, text parsing is easier in Perl/Ruby/Python/Swift/etc. As someone who knows C++, more thought is required to do the same thing as in a higher level language, although it runs much faster. If you just wanted to bootstrap the compiler, then you'd choose the easiest route to that. It could also be easier to read and understand than a C++ compiler.

Ada, for example.

There is an open source version available in every system supported by gcc.

However C++17 is quite safe, provided one doesn't follow "write C with C++ compiler" idiom.

> However C++17 is quite safe, provided one doesn't follow "write C with C++ compiler" idiom.

No, it's not. There is no use-after-free protection among other things. It doesn't matter how much you write code like C or not: it's just not safe.

Then better stop using LLVM on Rust.

Until then, those comments only annoy those of us that happen to like Rust, but don't find it mature enough to replace C++ on the use cases we happen to care about.

I didn't say you can't write useful software in C++. I said that C++ software is not, in general, memory safe. Sometimes the benefits of a particular piece of software (for example, having an excellent production-grade optimizer) outweigh its drawbacks (for example, not being memory-safe).

I don't think you'd find a single LLVM developer who would claim that LLVM is memory safe. Giving invalid IR to LLVM and not running the verifier frequently segfaults it, for example...

I do agree with that, but that is exactly why I always mention the "C with C++ compiler" idiom, which is usually followed by your remark.
safety is a spectrum, I think declaring it unsafe entirely might not be conducive to more interesting points