A lot of code is, but are you really going to ignore C++, Go, Rust, etc? Most games are written in C++, as are most large desktop apps.

All of them quite portable, with enough abstraction libraries available to make it a moot point, unless I really want to dive into details.

The only programming language I actually do have care about the underlying OS is C, due to its dependency on POSIX as an extension of ANSI libc.

C++ is fairly straightforward to port across architectures, especially since most architectures today are going to be 64-bit or more.

And you can be sure that every new ISA will have a port of GCC and LLVM, a Go compiler and everything else that's worthwile.

It may be, but from a user point of view, unless the developer targeted that architecture, you are out of luck using that software. And then you end up with “I need software 1 but it only works on OS A and cpu X and I also need software 2 that only runs on OS B and cpu Y”. We are back in the 80s!

Except today we have open source that can be recompiled without the author's explicit approval and we have a large collection of software that runs in some VM or other. There is also a variety of services as a software substitute that run on some cloud.

Actually I liked the 80's and early 90's.

Computers were sold with hardware and software designed to work together and provide a full stack experience.

Not a puzzle of bits-and-pieces.

Is this something the distribution maintainers are supposed to track? Let's say package x is available on Debian and decisions is available on the raspberry pi. The package maintainers on Debian side are the people who compile and ship the binaries for raspberry pi, no? Are the authors involved in this at all? Or is it that the package maintainers take a more handsfree approach and only build on platforms that the authors have said the software works on?