I didn’t interpret it as “say goodbye to niche arch support entirely” but rather as “it’s about time we stop externalizing to the OSS volunteer community the huge burden of supporting weird platforms, let’s rather shift that labor and cost onto the actual stakeholders of those architectures.”
That doesn’t imply end users of niche architectures are supposed to lose their favorite apps.
If you look at the market shares, you’ll quickly realize that this would mean abandoning all the BSDs, Haiku, Hurd, all the obscure Linux distributions and so on.
Just support macOS, RHEL/SLES, Debian, Ubuntu and Windows.
Everything else gets tagged with “UNSUPPORTED/WONTFIX”.
But please don’t complain when your favorite operating system is not supported.
Or, you know, we could just stop trying to tell others what targets to use.
And, FWIW, Rust is actually getting support for more architectures thanks to the GCC codegen and GCC frontend.
You're welcome to do it that way for your software. Others are allowed to choose some subset or superset of your choice. If they don't like your choice, they are allowed to fork the software to support what they want.
Case in point - the gcc projects for rust are not officially supported by rust. They are alternative rust compilers - the authors of those have explicitly stated they will follow the features (etc) of the official rustc, and maybe the rust language team will consider those other compilers when designing new features, but it's not on the rust language team to do so.
Another case in point - many projects don't support most linux distros. The job of the linux distro is maintain a fork (usually in the form of patches against upstream in the source package) of the software that works well with their system.
If updates are assuming they don’t have to support whatever those peculiarities are, won’t the support burden be massive? As opposed to starting in a supported state and enforcing a policy of not breaking existing support (until it’s so disused no one complains).
Who decides what degree of “popularity” is sufficient to maintain default support?
The problem is, I find I never get lovely clean patches, I just get GitHub PRs that day "hey, your code doesn't work on my weird CPU", or get a patch that fixes KettleBSD which breaks Cygwin on windows (which we care much more about supporting).
I don't think anyone is complaining about well written fully functioning patches, that break no existing features or OSes.
I think part of this could be fixed if Github, which seems to be the most used, lowest common denominator, had bug report mechanisms that were the equivalent of:
"This bug report has been reviewed and can't continue without more information. This report is now considered inactive unless you do these prescribed actions and report back with this specific information. Click here to submit this specific information."
Some projects seem to be assigning labels such as `needs-response` or `awaiting-user-response`, and have a bot in place that closes the issue if it gets stale.
> I don't think anyone is complaining about well written fully functioning patches, that break no existing features or OSes.
While most wouldn’t be complaining, I think any maintainer should absolutely feel free to refuse a well-written, fully working patch for any reason. For example, that patch may be too large or too complex, thus might become a liability at some point in the future. Maybe managing user expectations is a priority for the maintainer. Maybe they wish to reduce support burden because they’d like spend more time with their family. All that should be deemed normal and acceptable.
It can feel disappointing (numerous pull requests that I wrote have been denied or ignored), but I think it’s important that we, as a community, normalize that.
> Who decides what degree of “popularity” is sufficient to maintain default support?
Each upstream project and upstream distro is responsible for deciding on such a policy for themselves.
Many upstream distros do just that already with their packaging.
For example, you may not find a Linux kernel image that will work on your Pentium III CPU on Debian’s main repositories. Or an OpenSSL binary package.
Such decisions are highly arbitrary and at the discretion of the people who do the maintenance work and pay the hosting bills.
Being able to draw the line somewhere is a feature. It can help keep maintainers from burning out or giving up under the load of support requests.
Given the situation of a specific project, its individual goals, and the people involved, I would expect their decision to take into account many more factors than just the “so disused that no one complains” axis.
Firstly, unless I’m missing something, RISC-V seems to be on Rust’s Tier 2 with Host Tools, which is still way high up in Rust’s support pyramid.
Secondly, let’s assume – in favor of your argument – that for some reason, it’s still not working for RISC-V users. Then what keeps them from volunteering their time, labor, or money, and help make the thing fly and keep it that way? Niche or single-purpose distributions (such as Arch Linux ARM or AmberElec) have been doing just that anyway: those people regularly maintain special patches in order to support their specific target anyway, no matter whether the upstream projects are even interested in their platform, or whether they’re accepting their patches.
NEVER!