10 ms·

Why is Rustc not enough?

by solmag 5y ago

bestouff 5y ago
Rustc is based on LLVM. A GCC backend would target more architectures and be somewhat more optimized. Plus, a different implementation of a compiler frontend is, for some, a good thing to have for a language.
- volta83 5y ago
  rustc is backend agnostic, and currently has: an LLVM backend, a Cretonne backend, and a GCC backend. So rustc can already target _more_ architectures than this new GCC frontend, because it supports LLVM and Cretonne.
  - PoignardAzur 5y ago
    > a Cretonne backend I think you mean Cranelift?
    - volta83 5y ago
      Oops, yes, Cretonne was renamed to Cranelift a while ago. For some reason I still call it Cretonne.
  - bestouff 5y ago
    For now the only production-ready backend is the historical LLVM backends.
Tuna-Fish 5y ago
Because GCC is available on almost every platform that is in use, while LLVM is still much more limited. There are tons of embedded platforms that get rust support from this work.
- apendleton 5y ago
  It's true that if this project succeeds, that would be an outcome, but it's probably worth noting that you'd really only have to add support for the GCC backend to do that, and not reimplement the frontend as well (parsing, type checking, lifetime checking, etc.). There's an unrelated project working to do that: https://github.com/antoyo/rustc_codegen_gcc https://github.com/antoyo/rustc_codegen_gcc that would likely yield those same benefits for less effort.
- volta83 5y ago
  The "official" Rust frontend has a GCC backend that delivers this same value. There might be other value that a separate Rust frontend delivers over the official one, but this is not it.
  - southerntofu 5y ago
    > this is not it Wouldn't both approaches produce the same result (if they ever succeed to implement the whole spec)?
    - volta83 5y ago
      If GCC Rust is able to keep with Rust release cycle of new stable features every 6 weeks and new features / fixes on a nightly basis, sure.
      - southerntofu 5y ago
        Fair enough. Your parent comment seemed to imply otherwise :)
simion314 5y ago
If you have only one compiler then the compiler becomes the standard, so you get an IE like situation where standards would be ignored and implementation details would be abused. My question is why not have a GCC front end for all major used languages?
- paavohtl 5y ago
  > so you get an IE like situation where standards would be ignored and implementation details would be abused This is only the case when there already is a standard. If rustc is the only Rust compiler in existence, it effectively defines what Rust is. With one compiler there is no meaningful difference between implementation details and "standard" language behaviour.
  - pornel 5y ago
    > With one compiler there is no meaningful difference between implementation details and "standard" language behaviour. That's the point. There are odd edge cases that rustc has accepted by accident. Without a second opinion it's hard to tell what was intended, and what is a compiler bug.
    - volta83 5y ago
      To provide a second opinion, you can just open a rustc bug. In fact, the Rust bug repository has thousands of opinions about thousands of things.
      - Subsentient 5y ago
        And if you disagree with the unilateral decisions of the rustc developers? "Go fork it or write your own"? Yeah that's what we're doing. Don't be surprised when what was often a taunt in Rust-related arguments actually ends up happening. :^P
        volta83 5y ago
turbinerneiter 5y ago
Why have Android when there is iOS? Why have Chrysler when there is Ford?
flohofwoe 5y ago
See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090 Once a language is mature, it's better to have various competing implementations, if just for the reason that no accidential implementation-defined behaviour sneaks into the specification.
- ddek 5y ago
  > if just for the reason that no accidential implementation-defined behaviour sneaks into the specification How's this going for languages with multiple compilers, such as C++?
  - qalmakka 5y ago
    Pretty well I must say, modern C++ is very portable across different compilers. I wrote a quite complex piece of code two months ago, I fully tested it under GCC and Clang, and it built under MSVC without having to change almost anything. It's quite worse under C though, given that the standard way less comprehensive. You really have to stay away from those pesky Glibc extensions, and lots of stuff in the Standard C library is pretty unsafe or straight out broken (like strcpy and friends).
  - Subsentient 5y ago
    Indeed, C++ has benefited enormously from having multiple implementations. If one compiler produces results different from another, generally speaking, you've just found an issue in that compiler. The multiple implementations serves as checks and balances in a way.
    - yakubin 5y ago
      To be fair, off the top of my head, Clang and GCC: - lex differently; - have different baselines for what code even compiles: e.g. in GCC an out-of-range hex escape sequence in an integer character constant generates a warning; in Clang it generates an error. Additionally, for a long time on Windows MinGW's std::random_device()() always returned 0, being a real-world depiction of <https://xkcd.com/221/ https://xkcd.com/221/>. So you compiled for Linux with GCC and everything was fine; then you compiled for Windows with MinGW and silently something broke, which resulted in a suspiciously big number of hash collisions. Then again, those are illustrations of a poorly written standard, not of the idea of a standard, which has multiple implementations, being bad.
boondaburrah 5y ago
Not enough CPUs supported by LLVM. (personally, I want m68k and MIPS-I)
- volta83 5y ago
  So why don't you use the GCC backend for rustc?
- steveklabnik 5y ago
  LLVM does have an m68k backend, and there's an open PR on rustc to add it https://github.com/rust-lang/rust/pull/88321 https://github.com/rust-lang/rust/pull/88321
  - boondaburrah 5y ago
    Oh cool did they finally finish that? Time to get buildin' (I only use rust in my hobby so unfortunately it has to take a backseat a lot of the time)
masklinn 5y ago
One reason is that having multiple implementations can be useful to ferret out issues, a second is that the gcc framework wants to be a home for lots of language and that’s probably the reason why this was started, but the ecosystemic benefit is that gcc has a lot more (and more mature) support for rarer architectures and systems, and historically when companies provide a custom compiler for their weird-ass platform they do so using GCC (if only because it’s been there for way longer). So an eventual gccrust would allow using rust on a much wider set of platforms, which is nice.
- volta83 5y ago
  > 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?
bregma 5y ago
A single point of failure is always enough.
- volta83 5y ago
  How is rustc a single point of failure ?
Subsentient 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. 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.

Why is Rustc not enough?

by solmag 5y ago

Why is Rustc not enough?

Rustc is based on LLVM. A GCC backend would target more architectures and be somewhat more optimized. Plus, a different implementation of a compiler frontend is, for some, a good thing to have for a language.

volta83 5y ago
rustc is backend agnostic, and currently has: an LLVM backend, a Cretonne backend, and a GCC backend. So rustc can already target _more_ architectures than this new GCC frontend, because it supports LLVM and Cretonne.
- PoignardAzur 5y ago
  > a Cretonne backend I think you mean Cranelift?
  - volta83 5y ago
    Oops, yes, Cretonne was renamed to Cranelift a while ago. For some reason I still call it Cretonne.
- bestouff 5y ago
  For now the only production-ready backend is the historical LLVM backends.

Tuna-Fish 5y ago

Because GCC is available on almost every platform that is in use, while LLVM is still much more limited. There are tons of embedded platforms that get rust support from this work.

apendleton 5y ago
It's true that if this project succeeds, that would be an outcome, but it's probably worth noting that you'd really only have to add support for the GCC backend to do that, and not reimplement the frontend as well (parsing, type checking, lifetime checking, etc.). There's an unrelated project working to do that: https://github.com/antoyo/rustc_codegen_gcc https://github.com/antoyo/rustc_codegen_gcc that would likely yield those same benefits for less effort.
volta83 5y ago
The "official" Rust frontend has a GCC backend that delivers this same value. There might be other value that a separate Rust frontend delivers over the official one, but this is not it.
- southerntofu 5y ago
  > this is not it Wouldn't both approaches produce the same result (if they ever succeed to implement the whole spec)?
  - volta83 5y ago
    If GCC Rust is able to keep with Rust release cycle of new stable features every 6 weeks and new features / fixes on a nightly basis, sure.
    - southerntofu 5y ago
      Fair enough. Your parent comment seemed to imply otherwise :)

simion314 5y ago

If you have only one compiler then the compiler becomes the standard, so you get an IE like situation where standards would be ignored and implementation details would be abused. My question is why not have a GCC front end for all major used languages?

paavohtl 5y ago
> so you get an IE like situation where standards would be ignored and implementation details would be abused This is only the case when there already is a standard. If rustc is the only Rust compiler in existence, it effectively defines what Rust is. With one compiler there is no meaningful difference between implementation details and "standard" language behaviour.
- pornel 5y ago
  > With one compiler there is no meaningful difference between implementation details and "standard" language behaviour. That's the point. There are odd edge cases that rustc has accepted by accident. Without a second opinion it's hard to tell what was intended, and what is a compiler bug.
  - volta83 5y ago
    To provide a second opinion, you can just open a rustc bug. In fact, the Rust bug repository has thousands of opinions about thousands of things.
    - Subsentient 5y ago
      And if you disagree with the unilateral decisions of the rustc developers? "Go fork it or write your own"? Yeah that's what we're doing. Don't be surprised when what was often a taunt in Rust-related arguments actually ends up happening. :^P
      - volta83 5y ago

turbinerneiter 5y ago

Why have Android when there is iOS? Why have Chrysler when there is Ford?

flohofwoe 5y ago

See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090 Once a language is mature, it's better to have various competing implementations, if just for the reason that no accidential implementation-defined behaviour sneaks into the specification.

ddek 5y ago
> if just for the reason that no accidential implementation-defined behaviour sneaks into the specification How's this going for languages with multiple compilers, such as C++?
- qalmakka 5y ago
  Pretty well I must say, modern C++ is very portable across different compilers. I wrote a quite complex piece of code two months ago, I fully tested it under GCC and Clang, and it built under MSVC without having to change almost anything. It's quite worse under C though, given that the standard way less comprehensive. You really have to stay away from those pesky Glibc extensions, and lots of stuff in the Standard C library is pretty unsafe or straight out broken (like strcpy and friends).
- Subsentient 5y ago
  Indeed, C++ has benefited enormously from having multiple implementations. If one compiler produces results different from another, generally speaking, you've just found an issue in that compiler. The multiple implementations serves as checks and balances in a way.
  - yakubin 5y ago
    To be fair, off the top of my head, Clang and GCC: - lex differently; - have different baselines for what code even compiles: e.g. in GCC an out-of-range hex escape sequence in an integer character constant generates a warning; in Clang it generates an error. Additionally, for a long time on Windows MinGW's std::random_device()() always returned 0, being a real-world depiction of <https://xkcd.com/221/ https://xkcd.com/221/>. So you compiled for Linux with GCC and everything was fine; then you compiled for Windows with MinGW and silently something broke, which resulted in a suspiciously big number of hash collisions. Then again, those are illustrations of a poorly written standard, not of the idea of a standard, which has multiple implementations, being bad.

boondaburrah 5y ago

Not enough CPUs supported by LLVM. (personally, I want m68k and MIPS-I)

volta83 5y ago
So why don't you use the GCC backend for rustc?
steveklabnik 5y ago
LLVM does have an m68k backend, and there's an open PR on rustc to add it https://github.com/rust-lang/rust/pull/88321 https://github.com/rust-lang/rust/pull/88321
- boondaburrah 5y ago
  Oh cool did they finally finish that? Time to get buildin' (I only use rust in my hobby so unfortunately it has to take a backseat a lot of the time)

masklinn 5y ago

One reason is that having multiple implementations can be useful to ferret out issues, a second is that the gcc framework wants to be a home for lots of language and that’s probably the reason why this was started, but the ecosystemic benefit is that gcc has a lot more (and more mature) support for rarer architectures and systems, and historically when companies provide a custom compiler for their weird-ass platform they do so using GCC (if only because it’s been there for way longer). So an eventual gccrust would allow using rust on a much wider set of platforms, which is nice.

volta83 5y ago
> 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?

bregma 5y ago

A single point of failure is always enough.

volta83 5y ago
How is rustc a single point of failure ?

Subsentient 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. 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.