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