For instance systems with arm64 might need UEFI or if you enable SEV now you need additional support for that which is why I'd agree with Russ's stance on this.
Every time someone asks us to provide support for a new cloud instance type (like a graviton 4 or azure's arm) we have to go in and sometimes provide a ton of new code to get it working.
TamaGo already supports UEFI on x86, and that too would be part of the BSP for your application, not something that would need to be upstreamed to Go proper. Same for AMD SEV SNP.
As for you (nanovms) supporting new instance types, wouldn't it be nice to do that work in Go? :)
Edit: I wonder how big the performance impact would be if you used TamaGo's virtio-net support instead of calling from Go into nanos.
To be fair, there is a kernel - the Go runtime. But since there is no privilege separation it classifies as a unikernel. Performance gains should be expected compared to a system where you have to copy data to/from guest VM kernel space to guest VM user space.
> I wonder if it could run on cloud VMs?
Yes. TamaGo currently runs in KVM guests with the following VMMs: Cloud Hypervisor, Firecracker microvm, QEMU microvm.
> How tiny could the image become?
Roughly the same size as your current Go binary. TamaGo doesn't add much.
I like Anil Madhavapeddy's definition for such setups. A compiler that just refuses to stop:
MirageOS is a system written in pure OCaml where not only do common network protocols and file systems and high-level things like web servers and web stacks can all be expressed in OCaml but the compiler just refuses to stop ... compiler, instead of stopping and generating a binary that you then run inside Linux or Windows, will continue to specialize the application that it is compiling and ... emit a full operating system that can just boot by itself.
Timezone data etc: You would have to fetch that over the network, or from a metadata API such as the one Firecracker provides to VM guests.
We use a minimal image to run in on AWS Nitro VM and it contains only kernel, init.d, the Go application file and TLS certificate roots with the root filesystem mounted over tmpfs.
Note that Nitro VM uses a custom kernel provided by AWS so the new proposal is not relevant for us. But if we could run Go directly in that VM, it will surely makes things faster and saves like 10% memory overhead. And it will also avoid OOM killer and few other bad unwanted interactions between Go runtime and Linux kernel memory management.