4 ms·
> 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
by fyrerise 9y ago
> 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).
- steveklabnik 9y agorust 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.
- tmzt 9y agoCould 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?
- steveklabnik 9y agoThat's sort of MIR, but we have no intentions of stabilizing it any time soon, if ever.
- tmzt 9y agoYes, 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.
- steveklabnik 9y agoYeah, 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.