This right here, it's just crazy. On one project we invested in a private cache of prebuilt/binary pip wheels, as much as it complicated the build and maintenance, it saved us so much time and effort in the long run, and was ultimately a productivity boost.

I really like it that the x86 monoculture is being disrupted, and enjoy the benefits of low-wattage high-performance systems, but we still have a long way to go.

For the vast, vast majority of cases a VM can solve the issue of developing for linux/arm on an arm Mac.

It doesn't help so much if your Mac is still Intel based, admittedly.

In the .NET world we're developing on Windows/x64 and deploying on Linux/ARM64 en masse at this point. I haven't personally seen an issue yet where I had to debug a Linux- or ARM64-specific issue. I think different language ecosystems have wildly differing levels of readiness for this.

The platform of course matters less and less as you move into higher-level stuff. The necessary abstractions have already been built for you.

Though even in .NET you can still get bitten by assumptions about endianness, for example.

x64 and ARM64 are both little endian on Linux and Windows; there are never endianness issues when moving from Windows/x64 to Linux/ARM64. You can freely assume little endian and that's fine in this combination. It's one of many benefits ARM64 has going for it that IBM POWER does not.

The commercial Linux world (see https://github.com/open-mpi/ompi/issues/4349) and other open source OSes (eg FreeBSD) seem to have lined up behind little-endian PowerPC. IBM still has a big-endian problem with AIX, IBM i, and Linux on Z.