4 ms·

>> The only way to do this properly, if desirable, is to make GCC an official backend of the main frontend. That will defocus some progress that happens with LL

>> The only way to do this properly, if desirable, is to make GCC an official backend of the main frontend. That will defocus some progress that happens with LLVM (every feature has to be implemented on both backends) and can make dev lives hard (eg “oh this problem comes up with GCC so use the LLVM backend “) No. The correct way is to create a Rust language specification that describes what the correct behavior is. Then whether LLVM, GCC, or something else is used does not matter. There won't be one implementation with defacto behavior, there will be multiple implementations that follow the spec. This is the way mature languages work.

not2b 6y ago
It doesn't even have to stop progress. C++ does a new rev of the standard every 3 years. Rust has editions, which is a similar but less rigorous concept, and which could be made more rigorous.
- thesuperbigfrog 6y ago
  Exactly. The C++ standard (https://isocpp.org/std/the-standard https://isocpp.org/std/the-standard) is the specification that describes what a compiler must do to implement a particular "version" of C++ (for example, C++ 20). Just as there is a C++ standard and multiple C++ compilers that implement the standard, there should be a Rust standard and multiple implementations. This is the way that mature languages work.
  - steveklabnik 6y ago
    This is the way that very few languages work. Python is a great example of an extremely popular, mature language that does not work this way. It is unclear that most people think that this sort of process is required for “maturity.” If this is the benchmark, then among popular languages you basically have C, C++, C#, JavaScript, and... is that it?
    - zabzonk 6y ago
      I wouldn't say it's a benchmark, but surely Pascal, Fortran and COBOL (to name but three) are all standardised?
      - steveklabnik 6y ago
        There are more languages that have standards, sure, but the languages you mention, at this point, and in general, are mostly relegated to historical maintenance and maybe some very specific niches. To me personally, a “mature” language that’s not really being used isn’t the goal. And if developers truly believed standardization was valuable, you’d expect this property to give them a significant leg up against the sorts of languages like Ruby, Python, PHP, Perl, TypeScript, etc. That being said, I do think, considering it longer, there are languages that I am missing, like SQL, and ones that have a spec, even if it’s not under an ECMA/ISO process, like Java and Go, that I was forgetting. I still think that using this as a necessary condition for “maturity” is misguided.
        zabzonk 6y ago
        Well, I agree that standardisation and "maturity" (whatever that may mean) are not connected, but I think most C and C++ programmers (to name two very widely used languages that I personally have a lot of knowledge of) find the respective standards for those languages very helpful, and somewhat lament the lack of formal standards for other languages they may use.
        steveklabnik 6y ago
        Yes. I do think that standardization is generally good. I am pro Rust getting a specification! I just think it is one pro among many, and not something required for success.
        moltonel3x 6y ago
        The C and C++ specs are full of UB though, more like a "minimum common denominator" for compiler devs than a strict spec that users can rely on. It's way too easy to write spec-abiding code that behaves differently with different compilers/architectures/optimizations. Specs are definitely a good thing to have, but often they're just brandished as a bullet point without looking at the details: how good is the spec, what does it add over the existing tests/CI/RFCs/proofs, etc.
Blikkentrekker 6y ago
Such standardized specifications are typically a response to many divergent implementations existing and a need to standardize a common ground between them. Few languages find such specification before that time. Python also lacks it despite some competing implementations, since none actually diverge enough from CPython.
- vlovich123 6y ago
  PyPy famously diverges from it a lot (namely for native modules). Standardization is helpful for tool building and experiments (ie here are the invariants we’ll never change). Languages don’t work that way and seeing how C/C++ have evolved (or really failed to do so at a meaningful pace), I’m under the impression (clearly unpopular due to the downvotes) that standardization and multiple competing tool chains are the cause of a lot of unnecessary complexity (not just within the language but also users of said language).

not2b 6y ago

It doesn't even have to stop progress. C++ does a new rev of the standard every 3 years. Rust has editions, which is a similar but less rigorous concept, and which could be made more rigorous.

thesuperbigfrog 6y ago
Exactly. The C++ standard (https://isocpp.org/std/the-standard https://isocpp.org/std/the-standard) is the specification that describes what a compiler must do to implement a particular "version" of C++ (for example, C++ 20). Just as there is a C++ standard and multiple C++ compilers that implement the standard, there should be a Rust standard and multiple implementations. This is the way that mature languages work.
- steveklabnik 6y ago
  This is the way that very few languages work. Python is a great example of an extremely popular, mature language that does not work this way. It is unclear that most people think that this sort of process is required for “maturity.” If this is the benchmark, then among popular languages you basically have C, C++, C#, JavaScript, and... is that it?
  - zabzonk 6y ago
    I wouldn't say it's a benchmark, but surely Pascal, Fortran and COBOL (to name but three) are all standardised?
    - steveklabnik 6y ago
      There are more languages that have standards, sure, but the languages you mention, at this point, and in general, are mostly relegated to historical maintenance and maybe some very specific niches. To me personally, a “mature” language that’s not really being used isn’t the goal. And if developers truly believed standardization was valuable, you’d expect this property to give them a significant leg up against the sorts of languages like Ruby, Python, PHP, Perl, TypeScript, etc. That being said, I do think, considering it longer, there are languages that I am missing, like SQL, and ones that have a spec, even if it’s not under an ECMA/ISO process, like Java and Go, that I was forgetting. I still think that using this as a necessary condition for “maturity” is misguided.
      - zabzonk 6y ago
        Well, I agree that standardisation and "maturity" (whatever that may mean) are not connected, but I think most C and C++ programmers (to name two very widely used languages that I personally have a lot of knowledge of) find the respective standards for those languages very helpful, and somewhat lament the lack of formal standards for other languages they may use.
        steveklabnik 6y ago
        Yes. I do think that standardization is generally good. I am pro Rust getting a specification! I just think it is one pro among many, and not something required for success.
        moltonel3x 6y ago
        The C and C++ specs are full of UB though, more like a "minimum common denominator" for compiler devs than a strict spec that users can rely on. It's way too easy to write spec-abiding code that behaves differently with different compilers/architectures/optimizations. Specs are definitely a good thing to have, but often they're just brandished as a bullet point without looking at the details: how good is the spec, what does it add over the existing tests/CI/RFCs/proofs, etc.

Blikkentrekker 6y ago

Such standardized specifications are typically a response to many divergent implementations existing and a need to standardize a common ground between them. Few languages find such specification before that time. Python also lacks it despite some competing implementations, since none actually diverge enough from CPython.

vlovich123 6y ago
PyPy famously diverges from it a lot (namely for native modules). Standardization is helpful for tool building and experiments (ie here are the invariants we’ll never change). Languages don’t work that way and seeing how C/C++ have evolved (or really failed to do so at a meaningful pace), I’m under the impression (clearly unpopular due to the downvotes) that standardization and multiple competing tool chains are the cause of a lot of unnecessary complexity (not just within the language but also users of said language).