7 ms·

Why is it necessary to do this? I get that having multiple implementations of a language is a good thing. But why does GCC in particular want to do it, and why

Why is it necessary to do this? I get that having multiple implementations of a language is a good thing. But why does GCC in particular want to do it, and why with two separate efforts of different levels of ambition? Is it related to rust-in-kernel efforts? What stops using the normal rustc for that?

flohofwoe 4y ago
Because competition and choice is good? Even though having to support multiple C/C++ compilers can be painful at times for programmers, the competition between GCC, Clang and MSVC is definitely a good thing (imagine being stuck with MSVC on Windows when MSVC was about 15 years behind the C standard until recently). A separate Rust compiler may also uncover problems in the language or standard library design (e.g. if it's too much effort to write a Rust compiler from scratch that definitely isn't a good thing IMHO).
- alkonaut 4y ago
  Yes that much I got. It's a thing that would be nice to have. But that doesn't explain exactly why the GCC would be the ones doing it nor why there would be two separate projects.
  - bayindirh 4y ago
    Because having a Free implementation which complements the Open Source one is a great way to keep the language alive, evolve it in a saner way, and improve ways we thought it's impossible to do. clang made gcc and g++ better compilers. gcc-rs can do the same and help making rustc a better compiler and Rust a better language. For the record, I don't write Rust, because GCC has no Rust support yet. More specifically, I don't use LLVM-Specific languages due to LLVM's license and stance against GCC.
    - estebank 4y ago
      How is Rust not evolving in a sane way today?
      - bayindirh 4y ago
        I didn't say it's evolving in an insane way, however I believe the outcome improves when more people with different perspectives discuss on a matter. In other words, "If you want to go fast, go alone. If you want to go far, go together".
    - eru 4y ago
      > For the record, I don't write Rust, because GCC has no Rust support yet. More specifically, I don't use LLVM-Specific languages due to LLVM's license and stance against GCC. As far as I can tell, GCC is licensed under GPLv3 these days. LLVM is under a variation of the Apache License. https://www.apache.org/licenses/GPL-compatibility.html https://www.apache.org/licenses/GPL-compatibility.html suggests that you can use code under Apache License in a project that's under GPLv3. So someone could take legally LLVM, change the Readme and slap a GPLv3 license on it, and have the same license as GCC? (Assuming that the exceptions that LLVM's license has aren't a problem.) Would that fix your issues? Or what is your specific problem?
      - Thiez 4y ago
        What would be the point of that? Upstream will never accept GPL licensed patches and your fork is also available under the Apache license from the original source (except the readme changes that nobody cares about).
        eru 4y ago
        The point is that this way you can get an LLVM that's licensed the same way as GCC. This whole exercise has a point, if and only if there's a point to insisting that GCC's license is fine, but LLVM's license ain't. It's just a reduction. https://en.wikipedia.org/wiki/Reduction_(complexity) https://en.wikipedia.org/wiki/Reduction_(complexity) If you don't have any problem with the license of LLVM in the first place, the reduction is obviously useless to you.
        Thiez 4y ago
        I thought the point of having something GPL licensed would be that you actually get to enjoy/enforce the copyleft clauses of the GPL. By just relicensing an existing non-copyleft project and not following up with any significant development you only get the illusion of a copyleft project. If you are happy with this license mirage you are essentially saying you only care about the GPL name and not about copyleft. It's just nerdy virtue signalling.
    - josephcsible 4y ago
      You're opposed to even using LLVM just because of its pushover license? Isn't even RMS okay with that? Doesn't the usual guidance go like "copyleft free software is good to use and contribute upstream to, free but non-copyleft software is good to use but bad to contribute upstream to, and non-free software is bad to use and contribute upstream to"?
  - Karliss 4y ago
    Why GCC -> who else if not GCC? LLVM and GCC are more or less only big system programming compiler frameworks that support multiple programming languages and many backends. GCC already has frontends for Objective-C, Fortran, Ada, D, Go and few more not just C++ and C. It's much easier to add N+1 language to compiler that already supports N languages, instead of adding second language to a compiler which currently supports one. Rest of the compilers are mostly using LLVM as backend, or are made for single language and probably don't have enough resource to support more than 3 CPU architecture, not even talking about second language frontend. Can you name even one other compiler which would match those requirements? Only thing that comes to my mind is Borland, although I have no idea whether their compilers shared common backend or where they completely independent. I guess at some point Microsoft might have shared some of the parts for their .NET CLR langauges (Basic, C#, F# and managed C++/CLI ). While you could make a Rust frontend for .NET it would be somewhat pointless. Rust makes certain sacrifices in terms of ease of use, for the purpose of safe low level memory management. In a VM made for higher level garbage collected languages thats just unnecessarily complexity, without the benefits. After looking more I was also able to find thing called "Amsterdam compiler kit", but that seems more like academic exercise. Why two separate projects -> Think of it as short term vs long term solutions. Ideally in long term the multiple implementations for programing language would be completely independent, but it takes more work. In short term it's easier to glue together existing Rust frontend with GCC backend, while still getting many of the benefits of having multiple programming language implementations.
- hardware2win 4y ago
  >Because competition and choice is good? It is not that simple, there are pros and significant cons
jmillikin 4y ago
1. GCC supports more target platforms than LLVM, including many low-volume embedded systems that are unlikely to ever get upstream LLVM support. 2. The GCC developers are interested in supporting a broad set of languages that compile to native executables, and Rust is an increasingly popular language for systems programming. 3. Whether something is "necessary" or not has never been decisive in whether or not it happens. When presented with a programming challenge, why not try it and see what comes out?
- epage 4y ago
  For (1) there is a parallel effort to add a gcc backend to the rustc frontend.
- phkahler 4y ago
  4. Some would like to use th we same compiler for everything. Right now, building the Rust bit of Linux requires LLVM. Why shouldn't you be able to build everything using gcc alone?
  - duped 4y ago
    Because they're different languages? It's more insane to me that one wants the same tool to do everything rather than have different tools for different tasks. Like should Perl be compiled with GCC just to satisfy that requirement because it's used during the kernel build? That's ridiculous!
    - azov 4y ago
      Yeah, you start down this path and one day you end up with compilers for Go, or Ada, or Fortran, or who knows what else. How ridiculous would that be! PS. GCC stands for “GNU Compiler Collection”. All of the above is already there.
      - deleted 4y ago
        [deleted]
    - 4y ago
trelane 4y ago
We already have proprietary forks of LLVM. That's the whole reason Apple etc. started it instead of continuing with GCC. It's unclear to me what negatives a new, independent, Free implementation brings. On the other hand, the positives of it seem clear: an independent, Free implementation helps establish Rust the language and differentiate the language from a specific implementation of it.
nick_ 4y ago
The Rust... must... grow.

flohofwoe 4y ago

Because competition and choice is good? Even though having to support multiple C/C++ compilers can be painful at times for programmers, the competition between GCC, Clang and MSVC is definitely a good thing (imagine being stuck with MSVC on Windows when MSVC was about 15 years behind the C standard until recently). A separate Rust compiler may also uncover problems in the language or standard library design (e.g. if it's too much effort to write a Rust compiler from scratch that definitely isn't a good thing IMHO).

alkonaut 4y ago
Yes that much I got. It's a thing that would be nice to have. But that doesn't explain exactly why the GCC would be the ones doing it nor why there would be two separate projects.
- bayindirh 4y ago
  Because having a Free implementation which complements the Open Source one is a great way to keep the language alive, evolve it in a saner way, and improve ways we thought it's impossible to do. clang made gcc and g++ better compilers. gcc-rs can do the same and help making rustc a better compiler and Rust a better language. For the record, I don't write Rust, because GCC has no Rust support yet. More specifically, I don't use LLVM-Specific languages due to LLVM's license and stance against GCC.
  - estebank 4y ago
    How is Rust not evolving in a sane way today?
    - bayindirh 4y ago
      I didn't say it's evolving in an insane way, however I believe the outcome improves when more people with different perspectives discuss on a matter. In other words, "If you want to go fast, go alone. If you want to go far, go together".
  - eru 4y ago
    > For the record, I don't write Rust, because GCC has no Rust support yet. More specifically, I don't use LLVM-Specific languages due to LLVM's license and stance against GCC. As far as I can tell, GCC is licensed under GPLv3 these days. LLVM is under a variation of the Apache License. https://www.apache.org/licenses/GPL-compatibility.html https://www.apache.org/licenses/GPL-compatibility.html suggests that you can use code under Apache License in a project that's under GPLv3. So someone could take legally LLVM, change the Readme and slap a GPLv3 license on it, and have the same license as GCC? (Assuming that the exceptions that LLVM's license has aren't a problem.) Would that fix your issues? Or what is your specific problem?
    - Thiez 4y ago
      What would be the point of that? Upstream will never accept GPL licensed patches and your fork is also available under the Apache license from the original source (except the readme changes that nobody cares about).
      - eru 4y ago
        The point is that this way you can get an LLVM that's licensed the same way as GCC. This whole exercise has a point, if and only if there's a point to insisting that GCC's license is fine, but LLVM's license ain't. It's just a reduction. https://en.wikipedia.org/wiki/Reduction_(complexity) https://en.wikipedia.org/wiki/Reduction_(complexity) If you don't have any problem with the license of LLVM in the first place, the reduction is obviously useless to you.
        Thiez 4y ago
        I thought the point of having something GPL licensed would be that you actually get to enjoy/enforce the copyleft clauses of the GPL. By just relicensing an existing non-copyleft project and not following up with any significant development you only get the illusion of a copyleft project. If you are happy with this license mirage you are essentially saying you only care about the GPL name and not about copyleft. It's just nerdy virtue signalling.
  - josephcsible 4y ago
    You're opposed to even using LLVM just because of its pushover license? Isn't even RMS okay with that? Doesn't the usual guidance go like "copyleft free software is good to use and contribute upstream to, free but non-copyleft software is good to use but bad to contribute upstream to, and non-free software is bad to use and contribute upstream to"?
- Karliss 4y ago
  Why GCC -> who else if not GCC? LLVM and GCC are more or less only big system programming compiler frameworks that support multiple programming languages and many backends. GCC already has frontends for Objective-C, Fortran, Ada, D, Go and few more not just C++ and C. It's much easier to add N+1 language to compiler that already supports N languages, instead of adding second language to a compiler which currently supports one. Rest of the compilers are mostly using LLVM as backend, or are made for single language and probably don't have enough resource to support more than 3 CPU architecture, not even talking about second language frontend. Can you name even one other compiler which would match those requirements? Only thing that comes to my mind is Borland, although I have no idea whether their compilers shared common backend or where they completely independent. I guess at some point Microsoft might have shared some of the parts for their .NET CLR langauges (Basic, C#, F# and managed C++/CLI ). While you could make a Rust frontend for .NET it would be somewhat pointless. Rust makes certain sacrifices in terms of ease of use, for the purpose of safe low level memory management. In a VM made for higher level garbage collected languages thats just unnecessarily complexity, without the benefits. After looking more I was also able to find thing called "Amsterdam compiler kit", but that seems more like academic exercise. Why two separate projects -> Think of it as short term vs long term solutions. Ideally in long term the multiple implementations for programing language would be completely independent, but it takes more work. In short term it's easier to glue together existing Rust frontend with GCC backend, while still getting many of the benefits of having multiple programming language implementations.
hardware2win 4y ago
>Because competition and choice is good? It is not that simple, there are pros and significant cons

jmillikin 4y ago

1. GCC supports more target platforms than LLVM, including many low-volume embedded systems that are unlikely to ever get upstream LLVM support. 2. The GCC developers are interested in supporting a broad set of languages that compile to native executables, and Rust is an increasingly popular language for systems programming. 3. Whether something is "necessary" or not has never been decisive in whether or not it happens. When presented with a programming challenge, why not try it and see what comes out?

epage 4y ago
For (1) there is a parallel effort to add a gcc backend to the rustc frontend.
phkahler 4y ago
4. Some would like to use th we same compiler for everything. Right now, building the Rust bit of Linux requires LLVM. Why shouldn't you be able to build everything using gcc alone?
- duped 4y ago
  Because they're different languages? It's more insane to me that one wants the same tool to do everything rather than have different tools for different tasks. Like should Perl be compiled with GCC just to satisfy that requirement because it's used during the kernel build? That's ridiculous!
  - azov 4y ago
    Yeah, you start down this path and one day you end up with compilers for Go, or Ada, or Fortran, or who knows what else. How ridiculous would that be! PS. GCC stands for “GNU Compiler Collection”. All of the above is already there.
    - deleted 4y ago
      [deleted]
  - 4y ago

trelane 4y ago

We already have proprietary forks of LLVM. That's the whole reason Apple etc. started it instead of continuing with GCC. It's unclear to me what negatives a new, independent, Free implementation brings. On the other hand, the positives of it seem clear: an independent, Free implementation helps establish Rust the language and differentiate the language from a specific implementation of it.

nick_ 4y ago

The Rust... must... grow.