[danielheath]

There are _so many_ deploy issues surfaced by eg developing on a mac and deploying to linux/aarch64 (or, in my case, developing on x86 linux). Anytime you add a dependency on a package with a native component you're likely to have something to fix.

[rollcat]

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.

[electroly]

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.

[TillE]

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.

[electroly]

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.

[andrewf]

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.

[stephenr]

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.