I didn't know that, but it makes it a more interesting comparison. I imagine at least part of rewriting it in Go was to "eat your own dogfood".

Actually it was more like "new team got in charge" actually.

There is a FOSDEM 2019 talk about it.

Thanks! The talk:

"The clusterfuck hidden in the Kubernetes code base" https://fosdem.org/2019/schedule/event/kubernetesclusterfuck...

One wonders if there'll be a similar talk in a year...

> The audience walks away feeling empathetic that they aren’t alone in their journey to writing idiomatic Go and is now equipped with strong refactoring techniques developed by some of the world’s top engineers for the Kuberentes project.

As an occasional user of kubernetes, minikube etc. it's not something I would have guessed to have been developed by the word's top engineers.

I mean kubernetes tries to, and probably manages to provide an useful abstraction, but at a few million LOC and a few man-month of full time senior engineering effort to run anything in production it's not exactly a epitome of elegant and efficient engineering.

You would be surprised at the quality of Android tooling stable releases, to the point that now there is Project Marble in place to try to improve its image.

https://adtmag.com/articles/2019/01/17/project-marble.aspx

If you want to have some reading fun, check /r/androiddev/ every time there is a "stable" release.

Even people working for Google on Android tell me the tooling is pretty garbage, so I'm less surprised than you might think ;)

The interesting thing with Kubernetes is that it's basically a re-imagining of Borg, which one assumes was not a few million lines of code when it was already running all of Googles infra more than a decade ago. It's obviously not solving the exactly same problem (e.g. Google correctly recognized that DNS isn't so hot and wrote their own replacement protocol, BNS which wouldn't fly for external adoption etc.). But I'd be curious to know how Borg's code quality and size back when it became the standard way to run stuff at Google maybe 12 years ago compares to Kubernetes today.

I bet k8s would look different if it were written by developers used to a more limited set of cpu, io, and memory resources.

Well, given the hops one has to go through for the privilege to work at Google, another level of code quality is to be expected.

Wow. Didn't realize it was that bad:

> We look at what it would take to begin undoing the spaghetti code that is the various Kubernetes binaries

Well at least the developers are being frank about it I guess.

My guess would be more on the side of native binaries (i.e. no runtime JVM dep) and lower memory use, but could be that too.