4 ms·

Well for me personally, a big part of it is a conscious desire to reduce the unilateral control that the Rust Foundation and core rustc developers have over the

Well for me personally, a big part of it is a conscious desire to reduce the unilateral control that the Rust Foundation and core rustc developers have over the language. I find some of their decisions actively harmful for a systems language, and with multiple alternative implementations, particularly egregious decisions might not be so easy to impose. This is why I'm glad that a parser is also being written rather than a mere backend. In short, a big part of the motivation is a deliberate effort to decentralize Rust. That, and 1. GCC historically generates better code than LLVM, and 2. GCC supports far more platforms.

orra 5y ago
> some of their decisions actively harmful for a systems language That's quite a strong statement. What specifically do you dislike?
- Subsentient 5y ago
  Among other things, async was done quite poorly imho and I know I'm not the only one to think so, and a huge pet peeve of mine is how rustc prevents you from turning off specific optimizations when they can be harmful to your code, e.g. strict aliasing, which actually makes unsafe code more unsafe by producing subtle bugs rather than predictable, deterministic behavior.
  - steveklabnik 5y ago
    For some context, specifically, rustc has a "no compiler flags that alter language semantics" rule (editions are sorta this but also sorta not, it's too in the weeds for the purposes of this post, this would make a change an edition cannot make). What this person (I believe, I'm not gonna dig up the forum post to cross-check usernames) wants is something that they would describe as an optimization flag, but the rust/rustc devs would describe as a language dialect. This was therefore not accepted. (C and C++ compilers do have these sorts of flags.) If alternative compilers had such a flag, you'd end up with code that was incompatible with rustc, leading to an ecosystem split. This is one of the major fears within the community about alternative implementations. IIRC the GCC Rust developers have stated a desire for compatibility, and therefore I'm not sure that they would accept this flag either, but we'll just have to see I guess.
    - Subsentient 5y ago
      Rust must stabilize its ABI if it seeks to be a useful systems language. You usually don't have to worry about ABI for LLVM and GCC interaction, so why should you need to worry about rustc and gccrs interaction? C++ STL and MSVC are known exceptions. In other words, anything produced by gccrs will already be incompatible with rustc. Yeah that was me I'm afraid. That said, I strongly disagree that -fno-strict-aliasing changes language semantics in an appreciable way, since using it to deliberately circumvent the aliasing rules still wouldn't be sanctioned by Rust. You'd just have a predictable, mostly acceptable form of "UB" rather than whatever glitter the compiler feels like farting into your face. If I was asking for a flag that broke existing code, I'd understand, but since this change is totally backwards compatible, I don't understand the objection.
      - steveklabnik 5y ago
        ABI is a complete red herring. The issue is about taking source code that you've written in your almost-Rust and compiling it with Rustc, leading to miscompilations. EDIT, responding to yours: it was explained in the thread, at length: https://internals.rust-lang.org/t/add-rustc-flag-to-disable-mutable-no-aliasing-optimizations/14404 https://internals.rust-lang.org/t/add-rustc-flag-to-disable-... it's not backwards compatible. The very first post is the language team co-lead explaining: > Whether or not rustc makes use of the codegen backend's support for optimizing &mut using noalias, by specification and defition &mut is still an exclusive reference. Various parts of the language and library depend on that exclusivity for soundness. &mut is not the mechanism you're looking for.
        Subsentient 5y ago
        Again, UB is UB, and if the author of said program wrote it to rely on -fno-strict-aliasing in gccrs, that's probably bad code. It doesn't mean, however, that -fno-strict-aliasing isn't useful. The truth of the matter is that I'm horrified by stacked borrows and what it represents, because it will make unsafe code extremely painful to write and extremely brittle. Rust needs a way to opt-out of these aggressive optimizations, like every other systems language ever has had for the majority of their lifespans. A function attribute would be acceptable, but the truth is, Rust is not open to any such enhancements for unsafe code. They seem hell-bent on enforcing "safety" on deliberately unsafe code, even if it breaks that code in subtle ways. EDIT: I have no interest in arguing further. This is a hopeless and frankly rather disheartening topic for me. Rust has brought out more strong emotions from me than any other language I have ever used. I suppose why it matters to me is because I see such potential in Rust, and I feel it's being taken down the wrong path. But, that's just my opinion.
WhyNotHugo 5y ago
> Well for me personally, a big part of it is a conscious desire to reduce the unilateral control that the Rust Foundation and core rustc developers have over the language That's not really something they can do without hard-forking the language. They either stick to what the reference implementation does, or don't. But as soon as they don't, it's essentially a forked language with incompatible nuances.

orra 5y ago

> some of their decisions actively harmful for a systems language That's quite a strong statement. What specifically do you dislike?

Subsentient 5y ago
Among other things, async was done quite poorly imho and I know I'm not the only one to think so, and a huge pet peeve of mine is how rustc prevents you from turning off specific optimizations when they can be harmful to your code, e.g. strict aliasing, which actually makes unsafe code more unsafe by producing subtle bugs rather than predictable, deterministic behavior.
- steveklabnik 5y ago
  For some context, specifically, rustc has a "no compiler flags that alter language semantics" rule (editions are sorta this but also sorta not, it's too in the weeds for the purposes of this post, this would make a change an edition cannot make). What this person (I believe, I'm not gonna dig up the forum post to cross-check usernames) wants is something that they would describe as an optimization flag, but the rust/rustc devs would describe as a language dialect. This was therefore not accepted. (C and C++ compilers do have these sorts of flags.) If alternative compilers had such a flag, you'd end up with code that was incompatible with rustc, leading to an ecosystem split. This is one of the major fears within the community about alternative implementations. IIRC the GCC Rust developers have stated a desire for compatibility, and therefore I'm not sure that they would accept this flag either, but we'll just have to see I guess.
  - Subsentient 5y ago
    Rust must stabilize its ABI if it seeks to be a useful systems language. You usually don't have to worry about ABI for LLVM and GCC interaction, so why should you need to worry about rustc and gccrs interaction? C++ STL and MSVC are known exceptions. In other words, anything produced by gccrs will already be incompatible with rustc. Yeah that was me I'm afraid. That said, I strongly disagree that -fno-strict-aliasing changes language semantics in an appreciable way, since using it to deliberately circumvent the aliasing rules still wouldn't be sanctioned by Rust. You'd just have a predictable, mostly acceptable form of "UB" rather than whatever glitter the compiler feels like farting into your face. If I was asking for a flag that broke existing code, I'd understand, but since this change is totally backwards compatible, I don't understand the objection.
    - steveklabnik 5y ago
      ABI is a complete red herring. The issue is about taking source code that you've written in your almost-Rust and compiling it with Rustc, leading to miscompilations. EDIT, responding to yours: it was explained in the thread, at length: https://internals.rust-lang.org/t/add-rustc-flag-to-disable-mutable-no-aliasing-optimizations/14404 https://internals.rust-lang.org/t/add-rustc-flag-to-disable-... it's not backwards compatible. The very first post is the language team co-lead explaining: > Whether or not rustc makes use of the codegen backend's support for optimizing &mut using noalias, by specification and defition &mut is still an exclusive reference. Various parts of the language and library depend on that exclusivity for soundness. &mut is not the mechanism you're looking for.
      - Subsentient 5y ago
        Again, UB is UB, and if the author of said program wrote it to rely on -fno-strict-aliasing in gccrs, that's probably bad code. It doesn't mean, however, that -fno-strict-aliasing isn't useful. The truth of the matter is that I'm horrified by stacked borrows and what it represents, because it will make unsafe code extremely painful to write and extremely brittle. Rust needs a way to opt-out of these aggressive optimizations, like every other systems language ever has had for the majority of their lifespans. A function attribute would be acceptable, but the truth is, Rust is not open to any such enhancements for unsafe code. They seem hell-bent on enforcing "safety" on deliberately unsafe code, even if it breaks that code in subtle ways. EDIT: I have no interest in arguing further. This is a hopeless and frankly rather disheartening topic for me. Rust has brought out more strong emotions from me than any other language I have ever used. I suppose why it matters to me is because I see such potential in Rust, and I feel it's being taken down the wrong path. But, that's just my opinion.

WhyNotHugo 5y ago

> Well for me personally, a big part of it is a conscious desire to reduce the unilateral control that the Rust Foundation and core rustc developers have over the language That's not really something they can do without hard-forking the language. They either stick to what the reference implementation does, or don't. But as soon as they don't, it's essentially a forked language with incompatible nuances.