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.
Etcd may not be, but Consul is in my experience substantially easier() to run in production than ZK, and is also written in Go. I’d say this is nothing to do with implementation language and much more to do with a more understandable consensus model.
( 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)
I’m not sure that people are arguing about “supremacy” as much as they are arguing that Go was an attractive choice for the authors vis-a-vis other languages.
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.
Is the JVM's sandboxing still supported, patched and believed to be secure? I had assumed they gave up on it when they removed applet and webstart support.
Thought it over and you're right, Spark has some SecurityManager glue I've vaguely glanced at, but HDFS relies more on Kerberos than anything in-proc with the workers. IPC into an opaque worker binary would be a lot more painful but can be made to work.
