5 ms·

I've been running production grade Go apps[1] on aarch64 servers for ~ a year, written on macOS(x86_64), tested on aarch64 before deployment and never faced a s

I've been running production grade Go apps[1] on aarch64 servers for ~ a year, written on macOS(x86_64), tested on aarch64 before deployment and never faced a single instance where something didn't work because of the architecture. These are the benchmarks for different ARM platforms[2], where I had submitted one for Jetson Nano a year back and now it seems there's one for Apple Silicon. I'm not telling, no one would ever find cross platform issues with Go; I'm just curious to know what issues you have faced and whether it's because of Apple's extension of ARM instructions. [1]https://needgap.com https://needgap.com [2]https://github.com/golang/go/wiki/GoArm#jetson-nano https://github.com/golang/go/wiki/GoArm#jetson-nano

saagarjha 6y ago
The comment wasn’t really an attack on the languages being unportable itself but more that their toolchains are complicated and not very flexible, requiring a decent amount of additional work for new architectures, whereas a lot of the “./configure && make” style projects already work. Apple’s proprietary extensions don’t really affect porting efforts except in one specific case when writing high-performance JITs for language runtimes. (And there is a fairly simple patch to disable this entirely.)
- Abishek_Muthian 6y ago
  >chuckle a bit because neither language works right now. Not even their dependencies work. It’ll be a while before they will be supported. I'm not sure what's preventing you from giving a direct & specific answer. As it would be useful to know where Rust/Go's toolchains fail for using the code for cross - platform applications.
  - saagarjha 6y ago
    Rust is blocked on libffi, as are most things using Python (which includes cmake, and that precludes all of LLVM). I downloaded the Go bootstrap and it tried to link against crt0 directly and it's either looking up the wrong one or there is none for aarch64. It's also looking for a file called defs_darwin_arm.h which I don't have. Some warnings that will probably be problematic at the future related to the ABI defining char to be signed.
    - Abishek_Muthian 6y ago
      >I downloaded the Go bootstrap and it tried to link against crt0 directly and it's either looking up the wrong one or there is none for aarch64. Go team was already working on getting the toolchain to work on darwin/macOS before Apple announcement[1] because GOOS=darwin meant iOS(gomobile) and there are instructions available now[2] to build it successfully before the official patches. Your test results there would be a valuable contribution. >Some warnings that will probably be problematic at the future related to the ABI defining char to be signed You mean unsigned char? that's a common hurdle while porting x86 code to ARM. [1]https://github.com/golang/go/issues/38485 https://github.com/golang/go/issues/38485 [2]https://gist.github.com/tonistiigi/290d2e7118fe6f581e336bf3553b4501 https://gist.github.com/tonistiigi/290d2e7118fe6f581e336bf35...
- FullyFunctional 6y ago
  Is there a good public link to what those "Apple’s proprietary extensions" might be? Thanks.
  - saagarjha 6y ago
    https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon https://developer.apple.com/documentation/apple_silicon/port... https://siguza.github.io/APRR#a-new-jit-on-the-block https://siguza.github.io/APRR#a-new-jit-on-the-block
- qalmakka 6y ago
  > “./configure && make” style projects already work This is because Apple has a massive investment in LLVM, Xcode is completely based on it. When they unvealed Apple Silicon, the development toolkit and the new Xcode, Clang was already ready for macOS 11 on AArch64, a luxury the Go developers definitely didn't have. For instance, GCC is not ready and no one really knows when it will support desktop Darwin on AArch64 (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168#c6 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168#c6)

saagarjha 6y ago

The comment wasn’t really an attack on the languages being unportable itself but more that their toolchains are complicated and not very flexible, requiring a decent amount of additional work for new architectures, whereas a lot of the “./configure && make” style projects already work. Apple’s proprietary extensions don’t really affect porting efforts except in one specific case when writing high-performance JITs for language runtimes. (And there is a fairly simple patch to disable this entirely.)

Abishek_Muthian 6y ago
>chuckle a bit because neither language works right now. Not even their dependencies work. It’ll be a while before they will be supported. I'm not sure what's preventing you from giving a direct & specific answer. As it would be useful to know where Rust/Go's toolchains fail for using the code for cross - platform applications.
- saagarjha 6y ago
  Rust is blocked on libffi, as are most things using Python (which includes cmake, and that precludes all of LLVM). I downloaded the Go bootstrap and it tried to link against crt0 directly and it's either looking up the wrong one or there is none for aarch64. It's also looking for a file called defs_darwin_arm.h which I don't have. Some warnings that will probably be problematic at the future related to the ABI defining char to be signed.
  - Abishek_Muthian 6y ago
    >I downloaded the Go bootstrap and it tried to link against crt0 directly and it's either looking up the wrong one or there is none for aarch64. Go team was already working on getting the toolchain to work on darwin/macOS before Apple announcement[1] because GOOS=darwin meant iOS(gomobile) and there are instructions available now[2] to build it successfully before the official patches. Your test results there would be a valuable contribution. >Some warnings that will probably be problematic at the future related to the ABI defining char to be signed You mean unsigned char? that's a common hurdle while porting x86 code to ARM. [1]https://github.com/golang/go/issues/38485 https://github.com/golang/go/issues/38485 [2]https://gist.github.com/tonistiigi/290d2e7118fe6f581e336bf3553b4501 https://gist.github.com/tonistiigi/290d2e7118fe6f581e336bf35...
FullyFunctional 6y ago
Is there a good public link to what those "Apple’s proprietary extensions" might be? Thanks.
- saagarjha 6y ago
  https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon https://developer.apple.com/documentation/apple_silicon/port... https://siguza.github.io/APRR#a-new-jit-on-the-block https://siguza.github.io/APRR#a-new-jit-on-the-block
qalmakka 6y ago
> “./configure && make” style projects already work This is because Apple has a massive investment in LLVM, Xcode is completely based on it. When they unvealed Apple Silicon, the development toolkit and the new Xcode, Clang was already ready for macOS 11 on AArch64, a luxury the Go developers definitely didn't have. For instance, GCC is not ready and no one really knows when it will support desktop Darwin on AArch64 (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168#c6 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168#c6)