Certainly scripted languages run fine on ARM Linux, however there are some caveats worth mentioning. ARM JIT compilers for some platforms and languages may be not as mature or performant as their x86 counterparts since they haven't been battletested as much in the server landscape. Also, if you are using C extensions that don't compile to ARM, obviously that is going to affect you. And finally, if any part of your CI is building images containing native code (even if all of your code is say, Python,) you are going to need to duplicate that process for ARM, possibly requiring some retooling of your build system.

I am very curious to see how it plays out. I've been waiting for a cloud ARM offering from a major provider for a while now (there have been some smaller but notable players like Scaleway, but demand seemed to always outrun supply, and I couldn't get VMs running near me in America.)

I use an ARM laptop for travel. I've had a lot of problems with running Python code. Mostly data-science related. A lot of recompilation is required, which is a hassle. Also, sometimes you'll be constrained in what libraries you can use, because some of them simply don't work on ARM, due to ARM specific bugs. NUMBA is one that caused a lot of headache, but I think they got it fixed since.

Which one? I'm in the market for a super cheap one!

Asus C201P. ~180 euros. Very durable, battery lasts for 10 hours easy, more if only programming. It's preinstalled with ChromeOS. Installing Linux took some tinkering; there are some blog posts around that were very helpful.

You might also look at the Pinebook, 11" for $99. I'm considering one also.

I've looked at the Pinebook but 6 hour battery life isn't enough for me.

Yes, that’s exactly what the linked article mentions

  > If your application is written in a scripting language,
  > odds are that you can simply move it over to an A1 instance
  > and run it as-is. If your application compiles down to
  > native code, you will need to rebuild it on an A1 instance.

Heh, "rebuild it _on_"

They're clearly putting a hundred-mile moat between them and cross-compilation from the start :D

I wonder what their support stance will be when confronted with customer cross-compile scenarios.

I don’t think it is a moat, just stating the simple case.

I’ve spent a lot of time making cross-compile work for complicated builds. It can be tedious and frustrating fighting compilers and build systems to get it right.

Sometimes it is necessary because the target didn’t have a complete native toolchain, but other times because the target was just so incredibly slow for large builds.

I haven’t built anything with them, but these Arm servers appear to be neither of those two cases.

Might just be "figure it out for yourself".

I doubt it's that hard if you're using a language with a reasonable cross-compile toolchain. That will probably influence choice of technology for new things aimed at this kind of performance envelope.

No doubt a lot of existing software will be left out by cross-compilation being too much of a pain.

Golang has really nice cross compilation features, it's as easy as setting two environment variables `GOOS` and `GOARCH` when building.

I can confirm that cross-compiling for aarch64 should work without hiccups.

If you use a modern gitops CI/CD type workflow building containers automatically then you don't need to worry about the manual building part either - this can be done cleanly with automation

They acquired Annapurna Labs back in 2015 - I'm sure this is based on their work, they (Annapurna) were already building chips for Synology prior to the acquisition.

https://en.m.wikipedia.org/wiki/Annapurna_Labs

It is. They mention it in the second paragraph of the linked article.

They landed in a few routers as well: https://wikidevi.com/wiki/Annapurna_Labs

The actual CPU core designs are licensed from Arm (another commenter said they're Cortex A72s).

Properly written C is portable (and much faster than Python)

Depending on how you define "properly written." It was easy to write seemingly proper code that assumed TSO and worked for x86 but does not work on architectures with weak memory consistency.

Code that assumes TSO is likely broken on x86 as well. The use of the volatile keyword doesn't really change that in any meaningful way either, given that part of the language is a bit under-specified. Basically, C compilers are free to do a lot of non-obvious optimizations which can reorder around volatile accesses.

Put another way, there isn't anything in the base C spec which can provide a guaranteed memory ordering barrier, which is why you absolutely have to depend on 3rd party specifications to get those guarantees. For example, if a program is using pthreads or openMP, their synchronization primitives must be used as well to assure portability.

That isn't to say that given a particular piece of code and compiler/switches/version the resulting program is wrong, just that its quite possible changing compilers/flags may result in "incorrect" code generation.

True, but outside of memory ordering, x86_64 and ARM64 are probably among the easiest to port between. Endianness, alignment and type sizes are the same, for example. Plus a lot of code already has been ported to both.