Hacker News Reader

Comment by saagarjha | Hacker News Reader

> Also other popular languages like Rust and Go work well even on weird architectures and little known operating systems

As someone working on porting “everything” to a decidedly not weird architecture and a very well known operating system, I chuckle a bit because neither language works right now. Not even their dependencies work. It’ll be a while before they will be supported.

(Swift works perfectly, but it would be unfair to compare it because it had a strong investment made in it to work…)

View on HN

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

[2]https://github.com/golang/go/wiki/GoArm#jetson-nano

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.)

>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.

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.

>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

[2]https://gist.github.com/tonistiigi/290d2e7118fe6f581e336bf35...

Is there a good public link to what those "Apple’s proprietary extensions" might be? Thanks.

https://developer.apple.com/documentation/apple_silicon/port...

https://siguza.github.io/APRR#a-new-jit-on-the-block

> “./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)

Yes, because MacOS on ARM is a super common architecture in July 2020 :-)

macOS works, ARM has support for years; for many projects all you need to do is pass in the flags requesting support for both and they work pretty much out of the box. Some get a little confused about how such a thing could possibly exist, but I can’t really fault them for that :)

The problem about assumptions is that we can't live with them, but we can't also live without them.

Many so-called "cross platform" projects have had big surprises when it actually came time them to be ported to other platforms.

It's extremely rare for a project which has never been compiled and launched on another platform to actually require 0 porting effort for that platform once actually required to run there.

Yes, for all but the simplest or most abstracted projects sticking steadfastly to standardized features this is fairly hard to do. But the closer you stay stick to that, the more platforms your projects has been through, the more foundational (and less dependency-heavy) your project is, the more likely it will port with few or any changes. My preferred shell and text editor, for example, required zero changes; as did many core tools such as ncurses or make or autoconf. And on top of those it was easy to get things like perl or ninja up with perhaps a small tweak to their configure script or something.

The lowest common denominator leads to working with Stone Age tools. I'm not surprised that not everyone goes that route.

And regarding your porting, Perl, sure, was easy to port. What about CPAN? Want to bet how many Perl libraries will keel over? Same thing for Ruby/gems, Python/pip, etc.

Don't get me wrong, your work is nice, but the people that build on top of your work outnumber you by 2-3-5 orders of magnitude and not all of their porting efforts will be trivial.

This was the extent of the changes necessary to get Meson working on the system-provided Python: https://github.com/mesonbuild/meson/commit/85686e21d78a587de.... Surely that is not a "Stone Age tool"? The people doing the work right now to get foundational stuff working are doing that precisely to aid the porting efforts of the many, many developers that will depend on those things working in a few months when they have to port their own codebases.

How many third party Python libraries does Meson use?

Edit: I've checked, none. Most of the Python stuff out there will use at least some.

And they’ll probably have a harder job as a result.

When I was working porting code across multiple UNIXes during the 90's, I discovered how "portable" POSIX actually is.

> decidedly not weird architecture and a very well known operating system

Can you say which ones? It's hard to place your comment without details.

The context implies it’s macOS on Apple silicon.

In that case the comment makes no sense - the details of AArch64-based Macs have been made public just a few weeks ago. It takes a while to do port and test for a new platform, even if iOS was already supported.

It’s implied the OP isn’t considered part of the “public” for this issue.

No, I learned of it the same time you did, although I had a fairly good idea about when this was coming for a few years ;) And while I have a bit of additional information now, it's nothing that would really be useful for porting.

Unless they work for apple. Those on the inside have been toying with it for a while now.

Nope, just a third-party developer who until June knew of "aarch64-darwin-xnu" as "iOS" ;)

Yup, that’s what I’m doing. Just offering my comments on how difficult some projects are to port: some require no new code and some will require quite a bit, and some will be blocked on their dependencies being in the latter camp :)

Reply on news.ycombinator.com