4 ms·

Out of curiosity, why would the community maintain two compilers. Wouldn’t that be double the work?

by gobins 7y ago

EliRivers 7y ago
You mean like LLVM and GCC? Both compilers for C and C++ (and a lot more with various front ends). I can only imagine they're both maintained because people enjoy working on them and find them interesting projects to develop. When I find something interesting to work on, I certainly don't care that someone else is doing something similar somewhere else.
- lmm 7y ago
  LLVM got where it is primarily because of GCC's licensing (and because GCC's design is deliberately compromised to support that licensing). It's unlikely that LLVM would have been maintained otherwise, and I would expect GCC to fall by the wayside in due course.
  - EliRivers 7y ago
    I would expect GCC to fall by the wayside in due course This currently shows no sign of happening. What do you expect to change such that this happens? It's unlikely that LLVM would have been maintained otherwise Again, why? You're making this assertion as if it's fact, but there are a huge number of maintained pieces of software that do the same task as other maintained pieces of software. A great many pieces of software exist that didn't even get started until after similar software was already established. Do you have any logic behind your thinking beyond the fact that they're two pieces of software that do similar tasks?
    - tom_mellior 7y ago
      I think your parent is exaggerating, but they do have a point. I can't point you to a concrete example off the top of my head, but there is quite a bit of anti-GPL sentiment in (parts of) the LLVM community. Apple I think is somewhat invested in spreading FUD about the GPL. I once spoke to some LLVM developers from Apple who said that they didn't believe they were allowed to look at the assembly code emitted by GCC, for copyright reasons. Which is strange since GCC explicitly does not claim copyright on its output.
      - EliRivers 7y ago
        I think your parent is exaggerating, but they do have a point. I can't point you to a concrete example off the top of my head, but there is quite a bit of anti-GPL sentiment in (parts of) the LLVM community. That's why the LLVM people won't switch over to GCC, sure. But what do the GCC people think of it? If they're content to keep working on GCC, what's going to change such that they want to stop? I could imagine that if the LLVM group gets orders of magnitude ahead (seems unlikely - thus far, they seem to be mostly keeping up with each other in terms of performance and so on - but it could happen), GCC might start to be seen as a niche piece of legacy software and start to head towards retirement. Any other obvious pathways for the end of GCC?
        tom_mellior 7y ago
        Sorry, I should clarify: I think the OP had a point about licensing being a big factor in LLVM's uptake and especially its adoption by the likes of Apple and Google. I don't agree with the OP that this implies that GCC will be abandoned.
    - lmm 7y ago
      > This currently shows no sign of happening. What do you expect to change such that this happens? Just natural turnover. I expect GCC to struggle to attract new developers. When it was clearly best open-source optimizer there was a certain cachet to it, but now all the advantages are with LLVM. > Do you have any logic behind your thinking beyond the fact that they're two pieces of software that do similar tasks? Apple in particular are documented as having tested the limits of GCC's licensing before funding work on LLVM; I believe other corporate contributors have made comments along the same lines.
int_19h 7y ago
Having independent language implementations is a good way to flush out unwarranted assumptions and other warts in the spec.
- hsivonen 7y ago
  This is not an independent implementation, though.
cbmuser 7y ago
GCC supports several targets like alpha, hppa, ia64, m68k, sh, v850 and vax (and more) that the LLVM-based Rust does not support because LLVM lacks support for these targets.
- Twirrim 7y ago
  Okay, but: * Alpha is more than a decade past end of life. * Hppa is EOL as of 6 years ago. * ia64 goes EOL next month. .. and the list goes on. These aren't going concerns outside of some hobbyist work, and GCC has had difficulty retaining maintainers for some of the hardware and has threatened deprecation of them (in fact IA-64 is facing this exact situation and is going to be marked deprecated in GCC 10, and vanish in 11 https://gcc.gnu.org/ml/gcc/2019-06/msg00125.html https://gcc.gnu.org/ml/gcc/2019-06/msg00125.html). With instruction set support in that state, the odds are reasonable that bugs will be exposed, and difficulty will be had trying to support and fix them (exasperated by scarcity of hardware) Adding support for obsolete hardware is not much of a good argument for taking on the work of supporting two compilers.
  - hsivonen 7y ago
    Also, m68k has been proposed for removal from GCC. (Dunno what actually happened.)
    - saagarjha 7y ago
      Motorola 68000 is still widely in use; why would they remove it?
      - Twirrim 7y ago
        https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02044.html https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02044.html https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-m68k-Is-Safe https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-m... There are some back-end changes coming to GCC, and no one had ported m68k to it (presumably there is no maintainer for m68k in GCC?) The back-end code the m68k code was relying upon was going away, and it needed ported to use the modern one. Someone has stepped up and done that work, so it gets to live another day. https://gcc.gnu.org/backends.html https://gcc.gnu.org/backends.html based on this is looks like avr, cris, h8300, mn10300 and vax are yet to be ported away from cc0.
yitchelle 7y ago
Is it the same folks for the two compilers? I would welcome another rust compiler as it would give us choices.

Out of curiosity, why would the community maintain two compilers. Wouldn’t that be double the work?

by gobins 7y ago

Out of curiosity, why would the community maintain two compilers. Wouldn’t that be double the work?

You mean like LLVM and GCC? Both compilers for C and C++ (and a lot more with various front ends). I can only imagine they're both maintained because people enjoy working on them and find them interesting projects to develop. When I find something interesting to work on, I certainly don't care that someone else is doing something similar somewhere else.

lmm 7y ago
LLVM got where it is primarily because of GCC's licensing (and because GCC's design is deliberately compromised to support that licensing). It's unlikely that LLVM would have been maintained otherwise, and I would expect GCC to fall by the wayside in due course.
- EliRivers 7y ago
  I would expect GCC to fall by the wayside in due course This currently shows no sign of happening. What do you expect to change such that this happens? It's unlikely that LLVM would have been maintained otherwise Again, why? You're making this assertion as if it's fact, but there are a huge number of maintained pieces of software that do the same task as other maintained pieces of software. A great many pieces of software exist that didn't even get started until after similar software was already established. Do you have any logic behind your thinking beyond the fact that they're two pieces of software that do similar tasks?
  - tom_mellior 7y ago
    I think your parent is exaggerating, but they do have a point. I can't point you to a concrete example off the top of my head, but there is quite a bit of anti-GPL sentiment in (parts of) the LLVM community. Apple I think is somewhat invested in spreading FUD about the GPL. I once spoke to some LLVM developers from Apple who said that they didn't believe they were allowed to look at the assembly code emitted by GCC, for copyright reasons. Which is strange since GCC explicitly does not claim copyright on its output.
    - EliRivers 7y ago
      I think your parent is exaggerating, but they do have a point. I can't point you to a concrete example off the top of my head, but there is quite a bit of anti-GPL sentiment in (parts of) the LLVM community. That's why the LLVM people won't switch over to GCC, sure. But what do the GCC people think of it? If they're content to keep working on GCC, what's going to change such that they want to stop? I could imagine that if the LLVM group gets orders of magnitude ahead (seems unlikely - thus far, they seem to be mostly keeping up with each other in terms of performance and so on - but it could happen), GCC might start to be seen as a niche piece of legacy software and start to head towards retirement. Any other obvious pathways for the end of GCC?
      - tom_mellior 7y ago
        Sorry, I should clarify: I think the OP had a point about licensing being a big factor in LLVM's uptake and especially its adoption by the likes of Apple and Google. I don't agree with the OP that this implies that GCC will be abandoned.
  - lmm 7y ago
    > This currently shows no sign of happening. What do you expect to change such that this happens? Just natural turnover. I expect GCC to struggle to attract new developers. When it was clearly best open-source optimizer there was a certain cachet to it, but now all the advantages are with LLVM. > Do you have any logic behind your thinking beyond the fact that they're two pieces of software that do similar tasks? Apple in particular are documented as having tested the limits of GCC's licensing before funding work on LLVM; I believe other corporate contributors have made comments along the same lines.

int_19h 7y ago

Having independent language implementations is a good way to flush out unwarranted assumptions and other warts in the spec.

hsivonen 7y ago
This is not an independent implementation, though.

cbmuser 7y ago

GCC supports several targets like alpha, hppa, ia64, m68k, sh, v850 and vax (and more) that the LLVM-based Rust does not support because LLVM lacks support for these targets.

Twirrim 7y ago
Okay, but: * Alpha is more than a decade past end of life. * Hppa is EOL as of 6 years ago. * ia64 goes EOL next month. .. and the list goes on. These aren't going concerns outside of some hobbyist work, and GCC has had difficulty retaining maintainers for some of the hardware and has threatened deprecation of them (in fact IA-64 is facing this exact situation and is going to be marked deprecated in GCC 10, and vanish in 11 https://gcc.gnu.org/ml/gcc/2019-06/msg00125.html https://gcc.gnu.org/ml/gcc/2019-06/msg00125.html). With instruction set support in that state, the odds are reasonable that bugs will be exposed, and difficulty will be had trying to support and fix them (exasperated by scarcity of hardware) Adding support for obsolete hardware is not much of a good argument for taking on the work of supporting two compilers.
- hsivonen 7y ago
  Also, m68k has been proposed for removal from GCC. (Dunno what actually happened.)
  - saagarjha 7y ago
    Motorola 68000 is still widely in use; why would they remove it?
    - Twirrim 7y ago
      https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02044.html https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02044.html https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-m68k-Is-Safe https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-m... There are some back-end changes coming to GCC, and no one had ported m68k to it (presumably there is no maintainer for m68k in GCC?) The back-end code the m68k code was relying upon was going away, and it needed ported to use the modern one. Someone has stepped up and done that work, so it gets to live another day. https://gcc.gnu.org/backends.html https://gcc.gnu.org/backends.html based on this is looks like avr, cris, h8300, mn10300 and vax are yet to be ported away from cc0.

yitchelle 7y ago

Is it the same folks for the two compilers? I would welcome another rust compiler as it would give us choices.