I’m not bashing Go though. I appreciate the focus on readability among other things. It’s a fine language for the use cases it was actually designed for, like pushing petabytes of ad data to serving clusters all around the world with acceptable latency and reliability.
I guess the Genera, Xerox PARC, ETHZ, Microsoft folks are borderline dishonest.
Writing compilers is not systems programming in the sense that it requires a systems programming language, no. One could easily write a C compiler in Ruby, but we don't consider Ruby to be a systems programming language.
Thus, obviously, Go, despite not being a systems programming language, could be used to write the compiler for a systems programming language. I guess that is what Tamago is? I'm not going to read through the source to find out and the web page you linked is boring marketing copy.
TamaGo is a bare metal runtime for unikernels, whose main use is a commercial product for secure USB keys, sold by F-Secure.
Back on my youth, writing compilers was considered systems programming, in parity with kernel drivers, how things change.
I guess writing userspace drivers in hybrid kernels is also not considered systems programming.
Possibly related, building against foreign objects and manually setting up the FFI call: https://words.filippo.io/rustgo/.
What was good for C while it was gaining adoption, surely is good enough for Go.
Leaving aside the GC, until Go has a real FFI it's hard to to imagine it being a really great fit for systems programming when the systems are all not written in Go.