TamaGo – bare metal Go for ARM SoCs
In this technical retrospective (2020), @dgellow shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
Well, you might be surprised to know that there is not a single line of C involved in serving this connection as well as the underlying terminal and functionality.
I was quite dubious of this. Surely the Go runtime is written in C? Turns out that no, Go is self-hosting. The runtime for Go is written in Go. So if you remove the OS, which they did, you have reinvented the wheel! A rounder wheel, this time, to be sure.
The previous wheels I'm referring to are Pascal, Java, Lisp, Forth, Prolog machines. This wheel is a different shape because those others are dedicated, purpose-built hardware, that can only execute those languages.
I wonder can the same (as Tamago, not Pascal et al.) be done for Rust?
https://randoc.wordpress.com/2014/05/01/western-digital-pascal-microengine-wd900/ ↗
Last year I discovered TinyGo (tinygo.org). Looking at the list of supported hardware I see quite a few ARM SoCs there. I also believe Google supports the TinyGo project in some shape or form.
So why does TamaGo exists? (No snark, just curious)
A good intro to tamago: https://media.ccc.de/v/36c3-10597-tamago_-_bare_metal_go_framework_for_arm_socs ↗
I don’t really see the application for bare metal Go. If you’re creating a bare metal application you’re most likely doing it in order to achieve real time computation, something which a garbage collected language can’t offer.
Could this potentially be used to compile something like k8s (obv with a custom container engine) so that you could run k8s right on a SoC and no OS getting in your way?
This blog article from February of this year gives some context: https://labs.f-secure.com/blog/tamago/ ↗