4 ms·
"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
by leoc 13y ago
"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
- coldtea 13y agoWhy, is anyone using Go on 32-bit ARM and will miss this?
- patrickaljord 13y agoChromebooks and Android maybe although they're moving to 64-bit ARM.
- georgemcbay 13y agoI 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.
- enneff 13y agoCan you explain how the NaCl port would be useful to you on ARM platforms?
- georgemcbay 13y agoOne 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.
- enneff 13y agoThat 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.
- steeve 13y agoI 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 https://news.ycombinator.com/item?id=7219792
- wmf 13y agoThe lack of Android/ARM support earns a double facepalm.
- steeve 13y agoI'm running Go cli programs on android/arm just fine: https://news.ycombinator.com/item?id=7219792 https://news.ycombinator.com/item?id=7219792
- enneff 13y agoGo 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 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.
- kaib 13y agoIt 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.