> as I don't believe most companies would bother to port their software to another architecture
For a Java/Node/Python application, this means changing one line in a docker file, and running preprod/integration tests.
For a Java/Node/Python application, this means changing one line in a docker file, and running preprod/integration tests.
Ironically, the theory contradicts the practice and native code is often the easiest to port on new archs.
I have ported to ppc64be, POWER, armv7 and aarch64 several HPC stacks, it is often the native app made in C/C++/Fortran which is the easiest to port/recompile/cross-compile simply because:
- Their build system has been made from the beginning to handle multiple architectures.
- The compilers for C/C++ are the first thing to be ported and tested on a new arch.
At the opposite, python / node / java embed pretty often native modules hidden somewhere, with hand rolled compile scripts in pip / npm / maven and which are everything excepted robust and portable.
Java might surprise you, too, especially on EMR. I've found math, compression, and machine learning libraries that reach out to native code using JNI.
Native libraries are most often used to make boring things faster, use popular C libraries, and are already ported.
Unless your in-house library is using native bindings for custom code, it very likely will be a drop-in replacement.
ARM isn't so esoteric these days like it might have been 5-10 years ago.
[1]: https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-s...
Stay tuned!
My monitoring application was written in golang, and that made cross-compilation trivial - although I guess I'd made a little extra-effort to keep it all native and avoid CGO.