Hacker News Reader

Comment by l0b0 | Hacker News Reader

Sounds like this can be solved by adding support to LLVM. I realize that might be a tall order, but isn't that preferable to locking entire platforms out of a popular new language forever?

  > The LLVM developers have been somewhat leery of taking on new architectures, unless they can be convinced there will be long-term support for them, which is understandable, but makes the problem even worse.

Surely, if people actually care about these platforms there would be people willing to commit to this long term? If not, are people saying that everything needs to support all the GCC-supported platforms forever?

View on HN

I was wondering the same thing. It's not as though LLVM is some niche project that only Rust is using; it's the backend for a large number of compilers, and I imagine this will continue to be the case moving forward. There are now even languages that are written in languages that use LLVM for their backend, like gleam [1].

I think, ideally, there would be a concerted effort to extend LLVM compatibility to those platforms. But I don't think it's unreasonable to assume that there simply won't be--I sometimes run into problems on aarch64, and most of these are far more niche than that. As the article mentioned, it seems likely that eventually the ability for certain platforms for get support on new compilers will be a make-or-break for their ability to stay current with upgrades for a lot of the more fundamental packages.

Alternatively, I guess, there could be effort to get a new gcc-backend for more langauges; I believe there's an ongoing effort for Rust[2], but who knows down the line what that might look like. Eventually, this will probably need to come to a head.

[1] https://gleam.run/

[2] https://github.com/Rust-GCC/gccrs

If the Linux kernel also adds Rust as a dependency to build modules, gccrs could actually be a good solution for the platforms still supported by gcc.

It's ok for Gentoo to drop support for these platforms IMO, the least used architectures need to be relegated to the museum sometime.

> Surely, if people actually care about these platforms there would be people willing to commit to this long term?

In some cases more than others. I feel the pain of people who want to keep running private unique architectures. I wish it would be easier for them.

But mentioning s390? Companies that bought mainframes from IBM don't get to complain about compatibility with open source projects in my opinion. They can deal with that issue themselves and contribute back. (Or fund a solution) Show me how much extra you spent on wages and contracts related to that choice and I'll show you my tiniest violin.

And bear in mind that this is s390, not s390x. s390 is a 31-bit architecture that was superseded in 2000 by the 64-bit Z series, and support in the Linux kernel was dropped in 2015.

I had this with one of my own projects - a complaint that it didn't support an s390. I proposed a patch based on the described issue and stated it would be merged the moment someone who actually had an s390 tested it. Noone came forward. I'm certain a lot of these compatibility complaints fall into a similar area.

Yeah, the tradeoffs seem to be "add various gentoo/arch support to llvm" vs "nobody should use llvm for anything popular, because gentoo can't use it on abnormal architectures"

Put some of this upset-energy into building out gentoo+llvm. There's no way you're going to convince the entire programming world to stop using llvm at this point, even if you claim it's reasonable.

FWIW, an M68k backend for LLVM is on its way upstream (see reviews.llvm.org and search for "M68k").

I think it would also take some effort to add support for new platforms in rust, even if LLVM already supports the platform. The `std` library is pretty large, and it would take effort porting it. (nvm if their code is `nostd`)

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?

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.

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.

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

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?

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.

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.

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

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

Sir, you deserve a honorary MBA.

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.

Reply on news.ycombinator.com