The glaring omission from that long post is the term "opportunity cost".
Ensuring a code base indefinitely supports arbitrary architectures carries a substantial code architecture cost. Furthermore, it is difficult to guarantee testing going forward or that the toolchains available for those architectures will continue to evolve with your code base. I'm old enough to have lived this reality back when it was common. It sucked hard. I've also written a lot of code that was portable to some very weird silicon so I know what that entails. It goes far beyond endian-ness, that is just one aspect of silicon portability.
The expectation that people should volunteer their time for low ROI unpleasantness that has a high risk of being unmaintainable in the near future is unreasonable. There are many other facets of the code base where that time may be better invested. That's not "anti-portable", it is recognition of the potential cost to a large base of existing users when you take it on. The Pareto Principle applies here.
Today, I explicitly only support two architectures: 64-bit x86 and ARM (little-endian). It is wonderful that we have arrived at the point where this is a completely viable proposition. In most cases the cost of supporting marginal users on rare architectures in the year 2026 is not worth it. The computing world is far, far less fragmented than it used to be.
> Today, I explicitly only support two architectures: 64-bit x86 and ARM (little-endian). It is wonderful that we have arrived at the point where this is a completely viable proposition. In most cases the cost of supporting marginal users on rare architectures in the year 2026 is not worth it.
This - and efforts to reintroduce BE should be resisted in the same way as people who want to drive on the other side of the road for pure whimsy.
I note that we've mostly converged on one set of floating point semantics as well, although across a range of bit widths.
> Ensuring a code base indefinitely supports arbitrary architectures carries a substantial code architecture cost.
I'd say just the opposite; it nudges you towards well-factored approaches and ultimately carries a code architecture benefit, just like having automated tests or using structured programming.