[jandrewrogers]

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.

[lmm]

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

[tacitusarc]

For a relatively small set of dimensions this is true. But the more abstractions the code needs to accommodate, the trickier and more prone to leaky abstractions it becomes. Removing one axis of complexity can be incredibly helpful.

[PaulDavisThe1st]

For the Ardour codebase (922k LoC at present, ignoring the vendored GTK/Gtkmm trees), we've found that every new architecture and new OS/platform that we've ported to has thrown up challenges and notably improved the code. That has included FPU/SIMD specializations too.

[pjc50]

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

[nextaccountic]

Why not wasm?

[jltsiren]

Wasm is in an awkward place, because Memory64 is widely but not universally supported. Which means that if you want to support Wasm, you probably have to support 32-bit environments in general. Depending on the project, that can be trivial, but it may also require you to rewrite a lot of low-level code in the project and its dependencies.

[nextaccountic]

This just means 32 bits is still relevant..

Also: why not riscv?

Anyway, I think that most pain for being low level and portable is due to C and C++, and it's not as painful in Rust. In Rust it's not as common to use non-portable integers like C's int (there is isize/usize but they are used for indexing; logic is supposed to be done in i32/u32/i64/u64), and the Rust stdlib comes with excellent support for dealing with byte orders like https://doc.rust-lang.org/std/primitive.i32.html#method.to_b... (and for more support, usage of https://docs.rs/byteorder/latest/byteorder/ is widespread), among other things

I think it's more immediately clear when Rust code is non portable too. It's not uncommon for random C code to be plagued with undocumented portability issues (and as such, you can't assume that code is portable without some inspection), but unportable Rust code may fail to build on unsupported platforms, which is an excellent idea

[jltsiren]

I think it's the opposite. Rust encourages you to use usize everywhere, because most interfaces use it and you need explicit casts between integer types. In C++, you typedef custom integer types everywhere and rely on implicit casts to make things work painlessly. And then you hope that you are not shooting yourself in the foot with some edge cases in the casts.

[nextaccountic]

That's not my experience. Yes casts are annoying but in Rust usize generally means something is an index to a Vec or arena (generally speaking, it means the id of some entity). You generally should not do math with indices in your business logic but rather use some higher level interface that does the math for you, because if you mess up you will have an out of bounds bug (which in Rust is not UB, but it's still a panic). If you keep your usizes to be just indices, they will not pose a portability problem.

When I talk about a higher level interface it may be something like this https://crates.io/crates/typed-generational-arena those sort of things are very common in Rust. In here the index is an usize, but you don't directly do math with it (also you have a generation number to guard against index reuse), so you never experience any `as usize` thing.

Of course that's not applicable to everything. Some domains will naturally require doing arithmetic with indices, which is annoying in Rust. Hopefully you enclose this into a library and try to forget the horrors (rather than using usize everywhere, which is objectively the wrong thing to do)

Then you have libraries like petgraph that does use u32 indices by default, to save memory https://docs.rs/petgraph/latest/petgraph/graph/type.DefaultI...

[awilfox]

Ooh, another +1 for reasons to maintain 32-bit support. Thanks for the tip.