5 ms·

> One reason is that having multiple implementations can be useful to ferret out issues, Do we have proof backing up this claim? For example, a list of new pr

> One reason is that having multiple implementations can be useful to ferret out issues, Do we have proof backing up this claim? For example, a list of new previously-unrepported bugs that have been uncovered by the GCC Rust re-implementation of the Rust language frontend?

Subsentient 5y ago
I have literally had to read compiler source code to find out Rust behavior before, more than once. That should never happen. The more implementations of a language there are, generally speaking, the better understood a language is. C++ has only benefited from having multiple compilers. If you're afraid of fragmentation or Rust dying as a result of this, I can assure you that historically, the exact opposite takes place.
- volta83 5y ago
  > I have literally had to read compiler source code to find out Rust behavior before, more than once. Every single time I had to do this, I opened a PR to the Rust reference with the fix. :shrug: > That should never happen. Sure, and the way this gets fixed is with documentation. GCC frontends have this same problem. I've had to read the GCC C++ frontend source code a million times already to figure out if it was standard compliant. When it wasn't, I sent a patch fixing it, instead of.... starting rewriting a new frontend from scratch. Compared with GCC, the Rust frontend source code was almost every single time infinitely better documented. Many internal modules are actually intended to be read as documentation, and I do read the rendered compiler API docs every now and then when looking for something. The quality of GCC docs was... not great. > C++ has only benefited from having multiple compilers. C++ starting point was very different than Rust's. > If you're afraid of fragmentation or Rust dying as a result of this, I can assure you that historically, the exact opposite takes place. I'm not afraid, just curious about what value is in here. I don't see why anyone would use GCC Rust, instead of the GCC backend, for anything. Most real-world Rust projects use 100s of crates.io dependencies. All real-word Rust projects I use, use nightly, and crates from crates.io that work on nightly. No idea how GCC Rust could achieve "daily" parity with Rust for anything practical. What's the strategy here?
  - mempko 5y ago
    Having multiple implementations is a sign of a healthy programming language. C++, Rust's primary competitor in this space has multiple implementations and all are used by somebody. In fact, if rust as a language cannot deal with multiple compilers (ecosystem doesn't allow it as you described by your crates.io) then I don't see how it can overtake C++.
    - southerntofu 5y ago
      > if rust as a language cannot deal with multiple compilers (ecosystem doesn't allow it as you described by your crates.io) Why would that not be the case? crates.io is just a code repository like any other. You don't need crates.io to write/use Rust code, and crates.io has no specific requirement for a certain compiler. It just so happens that currently only the main implementation of Rust language (rustc) can compile all of crates.io repository, but this could change in the future.
    - myrrlyn 5y ago
      > Having multiple implementations is a sign of a healthy programming language this is frequently taken as axiomatic but there's no actual support for it in reality. there are plenty of healthy single-implementation languages (go, rust, scala, erlang) and plenty of unhealthy multi-implementation languages (c, d, sql, javascript) to go alongside the healthy/multi (python, ruby) and unhealthy/single (php, i guess, i don't care about this quadrant very much)
- volta83 5y ago
  > I have literally had to read compiler source code to find out Rust behavior before, more than once. That should never happen. Can you point us to the documentation bugs that you filled upstream for each of these issues ? I think it would make sense to tag them with "GCC Rust" or so, to be able to study them as a whole.
  - volta83 5y ago
    Plus I see the main value of GCC Rust in helping improve the Rust spec, so all bugs uncovered are definitely worth fixing.
rcxdude 5y ago
I don't know of anything with rust, but e.g. the csmith project fuzzing three C compilers has been extremely effective at finding bugs by using disagreement between them as a litmus test (it works by generating C programs which are guaranteed to be standards-compliant but with an unknown output and comparing the execution outputs between the compilers).
- volta83 5y ago
  Given that "Rust is the spec", and it changes on a daily bases, fuzzing it vs GCC Rust would give you a lot of disagreements, that would only tell you about the thousands of ways in which GCC Rust is not conforming with Rust. I'm not sure what this tells you about Rust. By definition, it is conforming with itself.
  - steveklabnik 5y ago
    Things that have been declared stable do not "change on a daily basis" though.
    - volta83 5y ago
      When was the latest Rust stable release - every 6 weeks - that did not change the "spec" at all, e.g., by adding new stable features or standard library APIs ?
      - steveklabnik 5y ago
        It is true that on a six-week basis we add new things. I should have been more specific, haha. The point is that the language does not make daily breaking changes, which is a reputation that we still sometimes have even after all of these years of no longer doing so. That said, you are still right that it is a thing that the gcc-rust developers will need to keep up with.
        pjmlp 5y ago
        In any case, one could consider the Rust epochs as main synchronization points anyway.
steveklabnik 5y ago
There is some really active discussion in the unsafe code wg repo by someone who is building an alternative compiler and has questions about corner cases. They largely seem like fruitful discussions.
- volta83 5y ago
  These discussions are worth having. Avoiding the discussions and "forking the frontend to do a different thing" because "omgz rustc docs are bad and rustc devs can't be trusted" doesn't seem too valuable to me (but I guess to some people).
  - steveklabnik 5y ago
    Agreed completely.

Subsentient 5y ago

I have literally had to read compiler source code to find out Rust behavior before, more than once. That should never happen. The more implementations of a language there are, generally speaking, the better understood a language is. C++ has only benefited from having multiple compilers. If you're afraid of fragmentation or Rust dying as a result of this, I can assure you that historically, the exact opposite takes place.

volta83 5y ago
> I have literally had to read compiler source code to find out Rust behavior before, more than once. Every single time I had to do this, I opened a PR to the Rust reference with the fix. :shrug: > That should never happen. Sure, and the way this gets fixed is with documentation. GCC frontends have this same problem. I've had to read the GCC C++ frontend source code a million times already to figure out if it was standard compliant. When it wasn't, I sent a patch fixing it, instead of.... starting rewriting a new frontend from scratch. Compared with GCC, the Rust frontend source code was almost every single time infinitely better documented. Many internal modules are actually intended to be read as documentation, and I do read the rendered compiler API docs every now and then when looking for something. The quality of GCC docs was... not great. > C++ has only benefited from having multiple compilers. C++ starting point was very different than Rust's. > If you're afraid of fragmentation or Rust dying as a result of this, I can assure you that historically, the exact opposite takes place. I'm not afraid, just curious about what value is in here. I don't see why anyone would use GCC Rust, instead of the GCC backend, for anything. Most real-world Rust projects use 100s of crates.io dependencies. All real-word Rust projects I use, use nightly, and crates from crates.io that work on nightly. No idea how GCC Rust could achieve "daily" parity with Rust for anything practical. What's the strategy here?
- mempko 5y ago
  Having multiple implementations is a sign of a healthy programming language. C++, Rust's primary competitor in this space has multiple implementations and all are used by somebody. In fact, if rust as a language cannot deal with multiple compilers (ecosystem doesn't allow it as you described by your crates.io) then I don't see how it can overtake C++.
  - southerntofu 5y ago
    > if rust as a language cannot deal with multiple compilers (ecosystem doesn't allow it as you described by your crates.io) Why would that not be the case? crates.io is just a code repository like any other. You don't need crates.io to write/use Rust code, and crates.io has no specific requirement for a certain compiler. It just so happens that currently only the main implementation of Rust language (rustc) can compile all of crates.io repository, but this could change in the future.
  - myrrlyn 5y ago
    > Having multiple implementations is a sign of a healthy programming language this is frequently taken as axiomatic but there's no actual support for it in reality. there are plenty of healthy single-implementation languages (go, rust, scala, erlang) and plenty of unhealthy multi-implementation languages (c, d, sql, javascript) to go alongside the healthy/multi (python, ruby) and unhealthy/single (php, i guess, i don't care about this quadrant very much)
volta83 5y ago
> I have literally had to read compiler source code to find out Rust behavior before, more than once. That should never happen. Can you point us to the documentation bugs that you filled upstream for each of these issues ? I think it would make sense to tag them with "GCC Rust" or so, to be able to study them as a whole.
- volta83 5y ago
  Plus I see the main value of GCC Rust in helping improve the Rust spec, so all bugs uncovered are definitely worth fixing.

rcxdude 5y ago

I don't know of anything with rust, but e.g. the csmith project fuzzing three C compilers has been extremely effective at finding bugs by using disagreement between them as a litmus test (it works by generating C programs which are guaranteed to be standards-compliant but with an unknown output and comparing the execution outputs between the compilers).

volta83 5y ago
Given that "Rust is the spec", and it changes on a daily bases, fuzzing it vs GCC Rust would give you a lot of disagreements, that would only tell you about the thousands of ways in which GCC Rust is not conforming with Rust. I'm not sure what this tells you about Rust. By definition, it is conforming with itself.
- steveklabnik 5y ago
  Things that have been declared stable do not "change on a daily basis" though.
  - volta83 5y ago
    When was the latest Rust stable release - every 6 weeks - that did not change the "spec" at all, e.g., by adding new stable features or standard library APIs ?
    - steveklabnik 5y ago
      It is true that on a six-week basis we add new things. I should have been more specific, haha. The point is that the language does not make daily breaking changes, which is a reputation that we still sometimes have even after all of these years of no longer doing so. That said, you are still right that it is a thing that the gcc-rust developers will need to keep up with.
      - pjmlp 5y ago
        In any case, one could consider the Rust epochs as main synchronization points anyway.

steveklabnik 5y ago

There is some really active discussion in the unsafe code wg repo by someone who is building an alternative compiler and has questions about corner cases. They largely seem like fruitful discussions.

volta83 5y ago
These discussions are worth having. Avoiding the discussions and "forking the frontend to do a different thing" because "omgz rustc docs are bad and rustc devs can't be trusted" doesn't seem too valuable to me (but I guess to some people).
- steveklabnik 5y ago
  Agreed completely.