Hacker News Reader

Comment by koolba | Hacker News Reader

NodeJS is in that category as well. If you avoid native modules it’s easy to cross deploy on ARM. The workload seem to translate well to the process model of scaling out as well.

View on HN

Really though, unless you're writing x86 assembly, any language should be just fine on ARM. The only potential holdp is is you rely on precompiled binaries at some point. Otherwise it should just be a matter of hitting the compile button again.

In C/C++ land the kind of ”Just try and see if it works” kind of development is super common in proprietary software. Leading to issues such as:

Using volatile for threadsafe stuff. Arm has weaker memory model than X86 so it requires barriers. C++ standard threading lib handles this for you but not everyone uses it.

Memory alignment. Arm tends to be more critical of that. While it’s impossible for well formed C++ program to mess it up it’s quite common for people just go ”Hey it’s just a number” and go full yolo with it. Because hey, it works on their machine.

Apple's recent 64-bit ARM processors now support unaligned memory access, so there's one porting problem out of the way:

https://developer.arm.com/docs/den0024/latest/an-introductio...

It's difficult to avoid native modules though. Many basic things like SQLite or image manipulation are binary blobs.

In SQLite's case (and probably in the case of most reasonably popular image manipulation libraries), those binary blobs very likely already exist or can be readily recreated. ARM is not some newfangled obscure architecture; SQLite's been used to great success on far more exotic platforms than that (including, I'd imagine, on devices running iOS).

I seldom see issues porting C and C++ to ARM unless people do weird things with casts that are undefined in the language spec but that work on X86 or use X86-specific vector intrinsics. Most well-written C and C++ compiles out of the box to ARM and just works.

Reply on news.ycombinator.com