I’ve tried it. It’s very neat. I wrote a PoC music player on it and it boots up and begins playing music in about 4 seconds if I recall. Has a neat optional web-based service control UI that lets you see the logs and stop/start the “services.” Has a cool dual-boot-image scheme so you can boot a new one and roll back to the old one if needed (takes double the space on the boot drive but it’s still pretty small).
It’s still kind of a toy, however. There is no C runtime, and the maintainer has declared that there never will be (part of the point of the project is not worrying about that kind of complexity) so including anything C-based is going to be an adventure/unsupported. And the maintainer’s use case is custom built personal servers, so he is explicitly ok with, for example, having to hardcode your wireless config because there is no (and apparently never will be) a wpa_supplicant.
But if it had a golang wpa_supplicant implementation and a graphics library (I’ve done a little fb drawing on it and it works but it really needs acceleration) it would make a really nifty platform for little devices with an HDMI UI.
You’re right about the lack of a C runtime being intentional. However, C programs can be run if you take on the task of keeping them up-to-date: https://gokrazy.org/prototyping/
Regarding WiFi, we have https://github.com/gokrazy/wifi which currently only works for unencrypted WiFi. If at some point there is a Go solution to configure encrypted WiFi, I’m all for it!
I use it to run internal services I don't want going down when I'm messing around in the homelab. Namely: internal DNS, MQTT broker and various prometheus pollers (e.g. unifi-poller). I'm a big fan of this project.
It’s still kind of a toy, however. There is no C runtime, and the maintainer has declared that there never will be (part of the point of the project is not worrying about that kind of complexity) so including anything C-based is going to be an adventure/unsupported. And the maintainer’s use case is custom built personal servers, so he is explicitly ok with, for example, having to hardcode your wireless config because there is no (and apparently never will be) a wpa_supplicant.
But if it had a golang wpa_supplicant implementation and a graphics library (I’ve done a little fb drawing on it and it works but it really needs acceleration) it would make a really nifty platform for little devices with an HDMI UI.