Of course I can, but the question is why would go out of my way to do any of that?

I was interested in trying the state of server-side ARM for my mostly-interpreted language, and I pretty much immediately found that it doesn't Just Work. I had a vision of spending many hours searching, creating and +1:ing GitHub issues and tracking discussions around "why package X doesn't work on ARM" and the developers saying at best "happy to accept patches" (which btw is the mantra for why "why package X doesn't work on Windows", and why you don't want to develop with Node on Windows to this day despite all of Microsoft's ecosystem work). Nope, not worth it.

I'm not interested in supporting ARM just for it's own sake. A 30% discount on the cloud instances is also not nearly enough for me or my team of developers to be spending any significant amount of time on this, solving problems unrelated to our core business.

Let's see again in a few years. Of course, if ARM development machines become mainstream by way of Apple, then the calculation changes completely.

> if ARM development machines become mainstream by way of Apple, then the calculation changes completely.

That's the biggest chance for ARM: having the notebooks/desktops that are good or even better for most potential users.

Chance for ARM? How can you say that with a straight face when ARM is the undisputed winner in the greatest market of all.

The chance for ARM to really get to be used for all purposes (desktop, server) in the context of the OP. The context of the discussion matters.

Aside from the fact that emulation is slow (and thus more annoying to test), now you have to contend with emulator bugs. Is your software crashing because your code is bugged or because the emulator is bugged? Or worse: your software may only be working because of an emulator bug.

Or your software may be working because the emulator was correct where your hardware stepping may be wrong (e.g., FDIV).