4 ms·
> The Rust compiler is slow because it’s doing a lot of work (the same reasoning) [...] This is commonly assumed but the evidence suggests otherwise. The borro
by tialaramex 2y ago
> The Rust compiler is slow because it’s doing a lot of work (the same reasoning) [...]
This is commonly assumed but the evidence suggests otherwise. The borrowck for example is not a large fraction of the compiler runtime.
So if you've just assumed this is correct, rather than you've collected evidence, I suggest your foundational argument needs re-evaluating.
As to the idea that you can assess C++ instead, not really, you need invasive language changes, Sean Baxter's "Circle" compiler provides a whole bunch of experimental features including his take on borrow checking, but you can't meaningfully check existing C++, it just gets rejected, you have to write your new checkable C++ instead.
- rbanffy 2y ago> you have to write your new checkable C++ instead. That was more or less where I was going. Existing code is mostly hopeless, so, maybe, a dialect that makes more of the developer’s intentions explicit would provide enough for more checking. I don’t have evidence that Rust’s checking is why it’s slow, but I assumed it was a good guess.
- tialaramex 2y agoI think I'd have guessed similarly, but then I read the data. I don't think a C dialect is a good idea. You want a blank slate, on which you can begin with your foundational concerns (e.g. constant time evaluation) rather than starting from C. There may be practical reasons to prefer how C spells things, the way Rust looks like a semi-colon language even though it's mostly an ML, but the core language isn't helpful.
- rbanffy 2y agoThe C dialect idea would be useful if you wanted to gradually take a code base in. You’d mark parts of it as unsafe/unchecked and new code could come in using the new constructs with a more convenient syntax.