Kubernetes was transpiled to Go from Java, so I wouldn’t use it as an example in support of your point. (Read the source code; it’s pretty obvious — and it’s been confirmed elsewhere.). Some components such as etcd, however, are pure Go.
Also with GraalVM you can equally support low memory, fast startup use cases.
( based on having spoken to hundreds of operators of both over the last few years, while (disclaimer) working for HashiCorp and other distributed system vendors, but also having personally run both at serious scale)
Getting into language or tool superiority arguments without deeply analyzing the environmental factors and use cases seems like a pointless exercise to me, and ought to be discouraged here IMO.
ZK is using Paxos and Etcd is using Raft. It's difficult to compare languages in this case as you will compare consensus algorithms mostly.
> Also with GraalVM you can equally support low memory, fast startup use cases.
How is GraalVM performance this days? Last time I've checked[1] it was a lot slower than JIT.
1. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
(Atomic broadcast can be reduced to consensus, but frames the problem differently.)