Gokrazy – Go Appliances
gokrazy.org
gokrazy.org
I experimented a few weeks ago with packaging a custom kernel and minimal Go init binary into a disk image bootable on GCE. No bootloader needed, just EFI loading the kernel directly.
For a low-powered device, would a Go usespace bring particular benefits? (Though, even the cheapest phones today aren't really "low-powered" anymore)
Edit: In order to preempt the argument others are having: Safer than C, anyways, while being much easier than rust.
I have used this in the past:
https://github.com/abice/go-enum
But mostly use protos as much as possible these days. (The enum is going to be in the API, might as well use the same object inside the app.)
https://www.withsecure.com/en/solutions/innovative-security-...
Look for TamaGo on the page.
It's basically the opposite of containers, which I like hehe.
https://github.com/cloudius-systems/osv
https://ops.city/ (also nanovms) - this is one that I actually got working to at least demo state
I didn't know about those. I kind of thought you may have used MirageOS, which I had read about earlier. It is done in OCaml.
Or TinyGo, https://tinygo.org/docs/reference/microcontrollers/
How does Go fare on single core machines like older RPi0 models?
I love that they basically reimplemented libc to get more performance, but they also threw away decades of edge cases that it doesn't (yet) handle very well. I'm confident they'll get there, eventually, especially when people do things like this and report issues.
It's absolutely a matter of allocation, since the more you allocate, the more work the GC will have to do. If you write clean, memory-friendly code (e.g. reusing buffers, favouring stack allocation), then you'll generate a lot less garbage and the GC will spend less time collecting it.
> Once your applications starts feeling some memory pressure
I rest my case.
It will run every 2 minutes, if it hasn't run otherwise
https://github.com/golang/go/blob/9b4b3e5acca2dabe107fa2c3ed...
Go just does incredibly well in these kinds of conditions. The only reason we allocate 128MiB is because that's the minimum Google Cloud Run allows - we'd probably go for 64MiB on most systems otherwise
Look, let me blunt, since you have insistently posted several times: You don't know what you're talking about. The code is open source, the algorithms publicly available, and it simply is not the case that Go is programmed to simply run up to gigabytes of memory usage before going "hurr durr I guess I should free some stuff". Like many other posters here, I also in possession of numerous 24/7 Go servers that run all sorts of things through them without needing gigabytes of RAM.
I can tell you what happened to you with high probability. You wrote a memory leak, and mistook the result for Go's error rather than yours. Hit your leaking code with the built-in memory profiler and figure out what you're leaking and fix it. It's OK, it happens to all of us, I've written many such leaks in many different languages, with many different allocation schemes.
RPis are abundantly capable of running Go. They can run a lot of Go. They're way, way above minimum spec. Of course Go won't let you magically hold a decompressed video stream in memory any more than anything else does or work other magic, but it's a heck of a lot more efficient than Python, and can run an awful lot of server in the resources a web browser takes just to display a blank window.
It’s entirely possible to run a server that will handle tens of thousands of req/sec on hardware with comparatively small amounts (by todays standards) of RAM e.g. 512MB
> It’s entirely possible to run a server that will handle tens of thousands of req/sec
Indeed, you can do this. I'm talking about what happens once the Go starts getting memory pressure and the GC starts dominating the CPU. This is what it is designed to do. If your code can prevent that from happening, you are correct then, as it won't be an issue.
That does not happen. You must be thinking of Java 15 years ago.
GOMEMLIMIT definitely improves things, taking the very blunt instrument GOGC out of people's hands, and does what they actually want instead, which is to prioritize GC only when you're about to run out of memory.
People dislike tunables like this, and rightfully so, but a similar problem exists somewhat insidiously in non-garbage collected languages. Calling malloc() and free() is not a zero-cost operation, and you can certainly waste CPU by calling free() when nothing actually needs the memory you are freeing. GC lets cases like "this is a CLI app, the system has 128GB of RAM, the working set size is 2GB, and it's over in 1 second" basically never do any memory freeing. You allocate as much as you need, GC never runs, and the app exits. That kind of optimization is actually pretty neat. But, for steady state servers that run for an unbounded period of time, it is inevitable that you are going to spend time trying to reuse memory that you no longer need, because the system only has a finite amount of memory. Then the compromises start to balance throughput with efficiency. gc + GOMEMLIMIT is a very nice compromise that is excellent for many applications, but no heuristic is perfect for every possible computer program.
Still even with limitations, there was a ton of stuff we could do in MS-DOS, let alone a more powerful system with dual core and built-in networking.
Go does not need me much memory, it's in the same ballpark as a C++ server, using way way less memory than Java / C#.
It works great! No memory pressure/GC issues at all. Its really not that hard to write go that can perform well in moderately constrained environments.
However, I don't like to have a Go compiler on the production machine for security reasons, as well as to reduce even more the system base.
I think instead that the compiler should be needed only to deploy binaries and should stay on the syadmin's machine. The Go toolchain is very good at cross-compiling, so there should not be a need for the compiler on the target machine.
gokrazy images are built whereever you like (typically your PC, or some more automated setup) and then deployed to the target device. There is no Go toolchain on the target device.