>Those mainframes your Bank runs? I'm sure they'd love to see all that "awful" FORTRAN or C or whatever other language rewritten in Rust. But if Rust as a platform doesn't support the architecture? Well then that's a non-starter

But Rust does support S390x?

>Worse still, Rust seems to basically leave anything that isn't i686/x86_64 or ARM64 as "Tier 2" or worse

Rust has an explicit documented support tier list with guarantees laid out for each level of support. Point me to a document where GCC or Clang lists out their own explicit guarantees on a platform-by-platform basis.

Because I strongly suspect that the actual "guarantees" which GCC, clang and so forth provide for most obscure architectures is not that much better than Rust, if at all - just more ambiguous. And I don't find it very likely that the level of quality control for C compilers on m68k or alpha or s390x is not, in practice, at least a bit lower than that provided for x86 and ARM.

We made s390x builds of all our tools (http://www.auxon.io) for an early customer that insisted on running their org on a leased machine from IBM.

It was actually a pretty good experience. It mostly just worked.

> But Rust does support S390x?

It's not a tier-1 target though.

And?

How extensively is GCC testing on s390x, and do they hard-block merging all patches on s390x support being 100% working, verified by said test suite in a CI that runs on every submitted patchset? Or at least hard-block releases over failing tests on s390x? Do they guarantee this in a written document somewhere?

If they do, then that's great, they can legitimately claim to have something over Rust here. But if they don't, and I cannot find any reference to such a policy despite searching fairly extensively, then GCC isn't providing "tier 1"-equivalent support either.

I work for Red Hat so I'm well aware that there are people out there that care a lot about s390x support and are willing to pay for that support. But I suspect that the upstreams are much looser in what they promise, if they make any promises at all.

> This specific line in Tier 2 would send most project managers running for the hills "Tier 2 target-specific code is not closely scrutinized by Rust team(s) when modifications are made. Bugs are possible in all code, but the level of quality control for these targets is likely to be lower"

Are you operating under the assumption that the largely implicit support tiers in other compilers are better? In other words: do you think GCC’s m68k backend (to pick an arbitrary one) has been as battle-tested as their AArch64 one?

(I think the comment about evangelists is a red herring here: what Rust does is offer precison in what it guarantees, while C as an ecosystem has historically been permissive of mystery meat compilers. This IMO doesn’t scale well in a world where project maintainers are trivially accessible, since they have to now field bug reports on platforms they can’t reproduce for and never intended to support to begin with.)

> do you think GCC’s m68k backend (to pick an arbitrary one) has been as battle-tested as their AArch64 one

m68k might be a bad example to pick. I was using gcc to target m68k on netbsd in the mid 1990s. It's very battle tested.

Also, don't forget that m68k used to be in all of the macs that Apple sold at one point before they switched to powerpc (before switching to x86 and the current arm chips). You could use gcc (with mpw's libs and headers) on pre-osx (e.g. system 7) m68k macs.

> m68k might be a bad example to pick. I was using gcc to target m68k on netbsd in the mid 1990s. It's very battle tested.

That was 30 years ago! Having worked on LLVM: it's very easy for optimizing compilers to regress on smaller targets. I imagine the situation is similar in GCC.

(The underlying point is simpler: explicit is better than implicit, and all Rust is doing is front-loading the frustration from "this project was never tested on this platform but we pretend like it was" to "this platform is not well tested." That's a good thing.)