Hacker News Reader

Hacker News

Comment by leoc | Hacker News Reader

Full thread

leoc

"Go 1.3 targets that command-line tool for 32-bit and 64-bit x86 architectures.

(NaCl supports 32-bit ARM, but we have no plans to support it.)"

epic facepalm

View on HN

The lack of Android/ARM support earns a double facepalm.

I'm running Go cli programs on android/arm just fine: https://news.ycombinator.com/item?id=7219792

Go already runs on linux/arm, which means it runs on Android. There are already Android apps that are at least partially written in Go (while Java still controls the UI). One example: https://play.google.com/store/apps/details?id=org.camlistore

The 'android/arm' mention in the presentation refers to writing native Android apps in Go.

Why, is anyone using Go on 32-bit ARM and will miss this?

Chromebooks and Android maybe although they're moving to 64-bit ARM.

I use Go on 32-bit ARM (Beaglebone Black, Raspberry Pi, Samsung ARM Chromebook, and a few old chumby imx233 devices), and having this would actually be useful to me.

In any case, I'm sure ARM support will be added in time (just not for 1.3 release) if not from the core team than by outside contributors. There are quite a lot of people using Go on ARM devices.

Can you explain how the NaCl port would be useful to you on ARM platforms?

One long-term project I've been working on (very off and on) is something like the chumby dashboard app system but for apps written in Go that can run on actual old chumby devices (or really any similar ARM device such as RaspPi, etc). Basically you'd end up with a bunch of mini apps that you rotate through with each app doing random things, like providing a clock display, or a short photo slideshow, or whatever.

Ideally the running apps would be sandboxed so they could be served from potentially untrusted sources and not do damage to the underlying OS or cause problems or privacy issues with other little apps that would rotate through running, so a framework like the one used as the basis for the Go playground would be ideal.

This is admittedly a very niche need and can be tackled by other OS-level sandboxing techniques (though at that level the support offered by different combinations of embedded Linux ARM ports and/or ARM CPUs makes things more complicated), but NaCL support in Go/ARM would be very convenient here.

This project aside, though, there were lots of listed plans for Go 1.3 in the presentation that I would prioritize way over ARM/NaCl.

That does sound really cool!

Sorry that we don't support NaCl/ARM code gen. Our use case (the Go Playground) only required amd64 support, which is just 386 code gen plus more hard bits. I'm sure if it were straightforward Russ would have just done the ARM port too, but as you probably know ARM is very different to x86 so it would have been another project entirely.

I am. Succesfully cross compiling Go 1.2 with CGO to android/arm and linux/arm just fine.

See my comment https://news.ycombinator.com/item?id=7219792

It works fine. When I did the initial implementation of the Go ARM compiler I mostly used my phone as a debug environment. Android was probably the only Linux distro where the compiler worked when 1.0 was released.

Reply on news.ycombinator.com