[dexterlemmer]

It's not just the GC, Go's Interfaces are very heavy weight (including in TinyGo). Its green threads are very heavy weight (including in TinyGo)... Oh. And a GC is really unacceptable in a kernel (though not necessarily in the rest of an OS) for all sorts of reasons, not just throughput but also latency and severe issues with FFI and concurrency and frankly how the heck are you even supposed to run a GC without a runtime in the first place? And speaking of which: TinyGo has a massive runtime that requires a sophisticated OS like FreeRTOS already installed on the system, not just for GC but for greenthreads, and, well, everything.

Just because nowadays even MCU's are so powerful that you can just waste an insane amount of resources on TamaGo and just because TamaGo seems to run on custom hardware/firmware that specifically provides it what it needs to directly run on the hardware without help from C/C++/Rust, doesn't mean Go is particularly viable for Android today.

Even more importantly. Google actually wants to use a safe language for Android. Go isn't safe the moment you go parallel/concurrent/async. Go also isn't memory safe for important OS tasks like direct memory access. Go also isn't null safe. Go also isn't typestate safe... Rust have all of the above mentioned safety in all of the above mentioned situations.

[pjmlp]

Ah the Rust advocay.

- Direct memory access requires unsafe.

- Rust is also not null safe, unless you validate all unsafe code blocks

- Rust is also not typestate safe, unless explicitly programmed that way

As for GC being or not acceptable on kernel, plenty of worksation OSes have proven it works, only politics have hindered their further development.

Go was just the example at hand, I would have used D or any other better prepared GC systems programming language.

And then there are those bare metal JVM and Erlang runtimes deployed into production, even in matters of life and death like weapon control systems in battleships and missile tracking radars.