(CC @golang/windows)

GCP's ARM64 hosts can't run ARM binaries in our experience -- are you confident that Azure's can?

I think this mostly comes down to a question of resources and spending. We don't currently have enough budget to run more builders. We've gone a long, long time without windows-arm, so it's not easy for me to see a need. Can someone explain the benefit?

GCP's ARM64 hosts can't run ARM binaries in our experience -- are you confident that Azure's can?

Haven't really tried that on Azure, but I have a Windows ARM64 dev box that is surprisingly happy to run ARM binaries.

I think this mostly comes down to a question of resources and spending. We don't currently have enough budget to run more builders. We've gone a long, long time without windows-arm, so it's not easy for me to see a need. Can someone explain the benefit?

I'm not particularly interested on the windows/arm port. My main motivation to submit this idea is to have a safety net when touching the Go runtime internals for Windows that affects all its supported architectures. Having said this, if you are running short on resources I would rather have them expended on windows/arm64. I can still test that I don't break anything crosscompiling from my arm64 dev box.

We've gone a long, long time without windows-arm, so it's not easy for me to see a need. Can someone explain the benefit?

I don't have an opinion of the benefit of maintaining the windows/arm port, but I do want to point out an inconsistency: given that our porting policy requires each port to have a running builder, and that we currently do not have one for windows/arm, if we decline to add a builder we should add it to the list of broken ports.