Hacker News Reader

Comment by fyrerise | Hacker News Reader

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.

View on HN

Multiple implementations of a compiler lets you implement the "Diverse Double-Compiling"[0] countermeasure to the famous "Reflections on Trusting Trust"[1] attack. You wouldn't necessarily use the C++ implementation in production, but it still improves the security of the Rust language just by existing.

[0] https://www.dwheeler.com/trusting-trust/dissertation/html/wh... (previous HN discussion at: https://news.ycombinator.com/item?id=12666923 )

[1] http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomps...

DDC is irrelevant here, DDC is an argument to not write the second compiler in C++ and write it in Rust too.

Having a Rust compiler in C++ is a mitigation to the trusting trust attack, period. You don't need DDC for this.

DDC is necessary when you have two self hosted compilers (e.g. GCC and clang). Here we have one self-hosted compiler (rustc), and one in another language (C++). To mitigate trusting trust in rustc, use mrustc to compile rustc, and then use that rustc to compile itself, and now you have a trusted binary (provided you trust your C++ compiler. you can fix this by DDCing the C++ compilers)

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?

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.

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

Yes, but I mean outputing actual Rust source but with generators or async/await expanded into calls to Futures. Similar to how Go is now bootstrapped from a down-level compiler.

Yeah, I get it. But that's what I mean; MIR is the common sub-language that's the same across epochs.

I don't think there's any real plans for a source-based approach. But epochs can only change a limited amount of things for exactly this reason; they minimize the compiler burden of supporting them.

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.

safety is a spectrum, I think declaring it unsafe entirely might not be conducive to more interesting points

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.

The Rust compiler infrastructure is built on LLVM (a C++ project), so this doesn’t seem terribly weird.

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

The core guidelines are very similar to Rust, in spirit and intent.

... but the details are very, very different. Unless I've missed significant revisions, data races and concurrency are a non-goal of the Core Guidelines, but are central to Rust.

That said, I always welcome tooling to make C++ safer; the end game is making programs better, not language partisanship!

I will say this for C++: post C++11, it’s one of the few languages in widespread use to have an explicitly defined memory model. The people working on C++ definitely do care about concurrency and parallelism. I’d still choose Rust over C++ for that kind of program any time I was given the choice, though. =)

Absolutely, I'm not saying they don't care; it's that solving that problem is an explicit non-goal of the GSL work. The C++ committee is clearly working on concurrency related things, I was reading the various coroutines TSes recently in fact, as we're working on similar things in Rust.

SaferCPlusPlus[1] is the library that's probably closer to Rust "in spirit and intent". And more importantly, safety effectiveness. And it does address the data race issue.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

Im in awe too how single handedly some folks have that drive to keep hitting the keyboard and put all the brain's power into a model defined by electricity and binary. Truly amazing! Bravo

Reply on news.ycombinator.com