4 ms·

>The problem with C/C++ stemmed from compiler vendors competing with each other to be "better" than their peers. Yea but this is Linux and OSS. NIHisms are fuc

>The problem with C/C++ stemmed from compiler vendors competing with each other to be "better" than their peers. Yea but this is Linux and OSS. NIHisms are fucking rampant everywhere. I give it a year before gccrs announces a new "gnurs" mode with language extensions.

saghm 3y ago
I'd be surprised about this mostly because I can't imagine anyone using gcc-specific Rust extensions. Not only does rustc have an extraordinary amount of traction by being basically the only choice up until this point, Rust doesn't really have the reputation of moving slowly to adopt new features; if anything, there's been as much skepticism about new features added over the years as excitement. I can honestly imagine more people adopting a Rust implementation with a commitment _not_ to add new features that are added to rustc than one that adds its own separate features. Even as someone who probably will never use gccrs, I think having more than one implementation of Rust is a good thing for the language (for all the usual reasons that get cited). In the long term, I'd love for Rust to eventually to be able to specify its semantics in a way that isn't tied to rustc, which is a moving target and gets murky when you consider implementation-specific bugs.
- nequo 3y ago
  > Rust doesn't really have the reputation of moving slowly to adopt new features There are some exceptions to this. Although there are possibly good reasons for such features moving slowly, a competing compiler could popularize them before they are stabilized in rustc. One example is generators[1] but there's a longer list in The Unstable Book.[2] [1] https://github.com/rust-lang/rust/issues/43122 https://github.com/rust-lang/rust/issues/43122 [2] https://doc.rust-lang.org/stable/unstable-book/language-features/generators.html https://doc.rust-lang.org/stable/unstable-book/language-feat...
  - estebank 3y ago
    Prevalent use of nightly Rust purely for specific unstable features would do the same. It's been a while since there has been a "must have" feature has kept people confined to nightly, though.
  - Guvante 3y ago
    I feel like having a distinct implementation that is unstable is more likely. Stabilizing things from rustc is a recipe for disaster as if rustc builds something new you are in a bad place.
Guvante 3y ago
NIHI is usually "using product X is almost as hard (or expensive )as building it" Linux tends to shun unfree software which is a very different take. Buy or build is roughly money vs time (aka money). Software freedom is not the same thing. Also why does software freedom lead to divergences? Certainly GCC partook in the arms race around C++ but recently they have been pretty good about aiming for full standard support as the goal. (The exception being proposed features but that is unavoidable when C++ prefers battle tested proposals)
- pjmlp 3y ago
  Actually one of the problems we are having with compilers catching up with ISO is that since C++11, features aren't battle tested, rather designed in paper or some special compiler branch, and eventually adopted by everyone.
  - Guvante 3y ago
    Honestly depending on the feature that might be for the best. If all three compilers have distinct on by default divergent settings that would be terrible. My point is outside of instances where everyone agrees something has to change you need a compiler branch at the minimum. This means the compiler you changed will get that feature first. Given it takes years to implement the full standard this leads to divergence between the compilers in standards compliance. Honestly all totally workable but makes talking about "standard C++" hard.
    - pjmlp 3y ago
      There are more than three compilers, and many of the changes if done at all in an existing compiler, are a mix between private branches and ongoing unstable features, hardly battle tested as the first standards were, when existing practice is what came into the standard.

saghm 3y ago

I'd be surprised about this mostly because I can't imagine anyone using gcc-specific Rust extensions. Not only does rustc have an extraordinary amount of traction by being basically the only choice up until this point, Rust doesn't really have the reputation of moving slowly to adopt new features; if anything, there's been as much skepticism about new features added over the years as excitement. I can honestly imagine more people adopting a Rust implementation with a commitment _not_ to add new features that are added to rustc than one that adds its own separate features. Even as someone who probably will never use gccrs, I think having more than one implementation of Rust is a good thing for the language (for all the usual reasons that get cited). In the long term, I'd love for Rust to eventually to be able to specify its semantics in a way that isn't tied to rustc, which is a moving target and gets murky when you consider implementation-specific bugs.

nequo 3y ago
> Rust doesn't really have the reputation of moving slowly to adopt new features There are some exceptions to this. Although there are possibly good reasons for such features moving slowly, a competing compiler could popularize them before they are stabilized in rustc. One example is generators[1] but there's a longer list in The Unstable Book.[2] [1] https://github.com/rust-lang/rust/issues/43122 https://github.com/rust-lang/rust/issues/43122 [2] https://doc.rust-lang.org/stable/unstable-book/language-features/generators.html https://doc.rust-lang.org/stable/unstable-book/language-feat...
- estebank 3y ago
  Prevalent use of nightly Rust purely for specific unstable features would do the same. It's been a while since there has been a "must have" feature has kept people confined to nightly, though.
- Guvante 3y ago
  I feel like having a distinct implementation that is unstable is more likely. Stabilizing things from rustc is a recipe for disaster as if rustc builds something new you are in a bad place.

Guvante 3y ago

NIHI is usually "using product X is almost as hard (or expensive )as building it" Linux tends to shun unfree software which is a very different take. Buy or build is roughly money vs time (aka money). Software freedom is not the same thing. Also why does software freedom lead to divergences? Certainly GCC partook in the arms race around C++ but recently they have been pretty good about aiming for full standard support as the goal. (The exception being proposed features but that is unavoidable when C++ prefers battle tested proposals)

pjmlp 3y ago
Actually one of the problems we are having with compilers catching up with ISO is that since C++11, features aren't battle tested, rather designed in paper or some special compiler branch, and eventually adopted by everyone.
- Guvante 3y ago
  Honestly depending on the feature that might be for the best. If all three compilers have distinct on by default divergent settings that would be terrible. My point is outside of instances where everyone agrees something has to change you need a compiler branch at the minimum. This means the compiler you changed will get that feature first. Given it takes years to implement the full standard this leads to divergence between the compilers in standards compliance. Honestly all totally workable but makes talking about "standard C++" hard.
  - pjmlp 3y ago
    There are more than three compilers, and many of the changes if done at all in an existing compiler, are a mix between private branches and ongoing unstable features, hardly battle tested as the first standards were, when existing practice is what came into the standard.