4 ms·

Why doesn't rust team add support for GCC instead? Seems like that would be a big win for them. Alternately, python cryptography could have chosen a different

by panny 6y ago

Why doesn't rust team add support for GCC instead? Seems like that would be a big win for them. Alternately, python cryptography could have chosen a different memory safe language, like Go, which is supported by GCC. Why did they intentionally choose a poorly fit language like Rust? Use the best tool for the job, yes?

adrianN 6y ago
For historic reasons GCC is architected to be much more difficult to use as a backend.
- arp242 6y ago
  More ideological reasons than historic ones. As far as I know, they're still concerned with the whole "someone might steal our frontend or backend!" thing, unless I missed something and this attitude changed?
  - SubjectToChange 6y ago
    AFAIK, the fear was that people would implement proprietary plugins for GCC and not upstream their changes and improvements. The classic Embrace, Extend, and Extinguish. Emacs modules were delayed for a long time for the same reason, RMS only approved them on the condition that they export GPL symbols. LLVM has changed the situation quite a bit though. GCC could make itself easier to hack on but it might be too late.
    - qalmakka 6y ago
      The irony of it is that no one was really interested in making a new frontend. LLVM was meant to be submitted to GNU, but RMS didn't really show interest in the 00's and instead it rebuffed attempts to disentangle GCC's frontend from the backend, forcing the creation of Clang. It's arguably true that RMS's zealotry actually backfired spectacularly.
      - arp242 6y ago
        rms actually missed the offer to donate LLVM to GNU because of the idiosyncratic way he uses email. See: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00594.html https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... I think it's probably for the best; having two competing solutions with different priorities is probably a win for everyone, gcc and clang users alike. gcc has improved much in the last few years in part due to LLVM/clang's pressure.
    - arp242 6y ago
      > LLVM has changed the situation quite a bit though. I've seen people bring this up a few years ago, but there wasn't much change in attitude on rms' end. I don't keep up on the day-to-day of gcc, so perhaps things changed in the last few years(?) I would be surprised if this would happen under rms' tenure though.
bobthebuilders 6y ago
I would not use any language with a GC for cryptography core. The GC pause would kill performance. No rust either. Just raw C and a brain.
tptacek 6y ago
Go is effective for whole-system reimplementations, but it's not a good fit for 1:1 C library reimplementations; that's a place where Rust shines.
qalmakka 6y ago
GCC support would only add backends for very obscure or borderline abandoned platforms, because everything else is either in the process of being merged into LLVM (i.e. ESP32 Xtensa) or it's already supported. The main benefit of a GCC-based Rust compiler would be disentangling Rust from rustc, specification from implementation.
higerordermap 6y ago
Sir, you deserve a honorary MBA.

by panny 6y ago

adrianN 6y ago

For historic reasons GCC is architected to be much more difficult to use as a backend.

arp242 6y ago
More ideological reasons than historic ones. As far as I know, they're still concerned with the whole "someone might steal our frontend or backend!" thing, unless I missed something and this attitude changed?
- SubjectToChange 6y ago
  AFAIK, the fear was that people would implement proprietary plugins for GCC and not upstream their changes and improvements. The classic Embrace, Extend, and Extinguish. Emacs modules were delayed for a long time for the same reason, RMS only approved them on the condition that they export GPL symbols. LLVM has changed the situation quite a bit though. GCC could make itself easier to hack on but it might be too late.
  - qalmakka 6y ago
    The irony of it is that no one was really interested in making a new frontend. LLVM was meant to be submitted to GNU, but RMS didn't really show interest in the 00's and instead it rebuffed attempts to disentangle GCC's frontend from the backend, forcing the creation of Clang. It's arguably true that RMS's zealotry actually backfired spectacularly.
    - arp242 6y ago
      rms actually missed the offer to donate LLVM to GNU because of the idiosyncratic way he uses email. See: https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00594.html https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00... I think it's probably for the best; having two competing solutions with different priorities is probably a win for everyone, gcc and clang users alike. gcc has improved much in the last few years in part due to LLVM/clang's pressure.
  - arp242 6y ago
    > LLVM has changed the situation quite a bit though. I've seen people bring this up a few years ago, but there wasn't much change in attitude on rms' end. I don't keep up on the day-to-day of gcc, so perhaps things changed in the last few years(?) I would be surprised if this would happen under rms' tenure though.

bobthebuilders 6y ago

I would not use any language with a GC for cryptography core. The GC pause would kill performance. No rust either. Just raw C and a brain.

tptacek 6y ago

Go is effective for whole-system reimplementations, but it's not a good fit for 1:1 C library reimplementations; that's a place where Rust shines.

qalmakka 6y ago

GCC support would only add backends for very obscure or borderline abandoned platforms, because everything else is either in the process of being merged into LLVM (i.e. ESP32 Xtensa) or it's already supported. The main benefit of a GCC-based Rust compiler would be disentangling Rust from rustc, specification from implementation.

higerordermap 6y ago

Sir, you deserve a honorary MBA.