I think you missed the point. What about all the dependencies of your code that are only compiled for x86_64? The article isn't talking about native apps on the laptop, it's about apps that run on a server but that you are developing locally.

You can't run your x86 docker image on your ARM mac without emulation. You can't run your x86 Windows VM without emulation etc.

Of course there are solutions like using a remote server or a VM in the cloud, but if you're buying a decent machine then you would normally expect to be able to run these things locally.

Do you have any examples of this? The last time I tried an AWS ARM server, it was literally no modification other than changing the server type — Linux has run on ARM for many years and Apple is far from the first company to use the platform.

For example, back in 2017 Cloudflare was basically looking at this as a question of which hardware ran most cost-effectively rather than having engineering heroics first: https://blog.cloudflare.com/arm-takes-wing/

Mono and .NET Core run terribly on ARM. I have several containerized C# apps that I need to run on x86_64 hosts, because on ARM they'll just crash randomly.

I want to say Oracle database clients as an example.

My company definitely had problems to get database drivers to work generally speaking and on both 32 bits and 64 bits. Have a look at postgres, oracle, cassandra, redis, sybase to name a few, I am not sure which one was worse, it wasn't me doing the work. But I've seen some of the C and C++ dependencies that needed to compile with the errors that happened and that was horrendous.

Fair enough — I've used Oracle's products enough to know that software distribution and packaging is not a priority there.

I've been using postgres, cassandra, redis and mysql/mariadb on aarch64. Only ran into issues with MySQL, which we rootcaused to some weird atomic locks not working as expected on the first generation of ARMv8(.0) a couple years back.

That’s a good moment to make your c/c++ code more robust, and cross-platform, like the languages they are

The problem wasn't in our code, it was in the database code that was either from open source or from a vendor.

If you want a sample. Try to install the cassandra client library in python. It will pull in and compile all sort of shit. That's supposed to be python and easily cross platform.

Yes, so time for them to clean up their mess ;)

Reading the comments here flow something like this: 1. complain that switching to ARM is a mess 2. no it's not a mess, it's easy 3. no, see it's a mess 4. fine, clean up the mess.

Yes, we should clean up the mess! It doesn't mean it's not a mess. And I think the mess is actually still understated.

I think it will come down to PRs accepted. So it's your mess in the end as it depends on the companies strategy.

AWS has put out some very impressive ARM instances running on the Graviton2 processors. The reviews I read show better performance per dollar. So maybe the solution is to further embrace ARM and run your code on ARM servers?

This will always be a problem, unless one emulates the x86_64 architecture, which is then again the other problem w/ Docker. I assume main libraries (i.e. dependencies) are already or will be ported, so theoretically recompilation should work for many, although not the most applications. Other applications will need to either change dependencies, or port dependencies to enable full performance.

Why not re-compile the dependencies so they run locally too? Am I missing some constraint?

I mean the post is technically right. You're probably better of skipping the first generation of ARM Macs until software support happens unless you're someone who wants to work on that software support.

Hardly. You’re investing a great deal of effort in building a parallel set of images that probably will never see production.

The one use case when this might be viable is targeting AWS Graviton2. Does anybody know if you can run an emulated Graviton2 on ARM Mac?

Parallels on Arm macOS simulates the Snapdragon 835 SoC to emulated operating systems.

There are very few packages compiled for ARM on PyPI, and there are more than a few packages on PyPI that are a pain to build from source.

Yeah, ARM is coming and docker will move to support it. We already have this: https://docs.docker.com/buildx/working-with-buildx/

Things like the pinebook pro (and hopefully more linux ARM devices) will keep pushing this further.

Docker came to the ARM-based raspberry pi in 2016: https://www.raspberrypi.org/blog/docker-comes-to-raspberry-p...

I know of several in production embedded devices running docker, and have worked on a few...It's already here and works great.