Kubernetes was originally written in Java and rewritten in Go after some Go advocates joined the team.
Docker was originally written in Python and rewritten in Go after some Go advocates joined the team.
Don't mix technical capabilities with people wanting to refresh their CVs.
Just to be clear, this didn't go very far. It's more like Brendan was willing to write Java, and a lot of other folks hate it. I don't think any of the core folks were Go advocates, just most of "us" were C/C++ people. Docker itself being in Go, meant it would lower a lot of friction, and besides we had great tooling for Go.
tl;dr: It was really "Should we (re)write this in C++? Eh, how about Go?".
And to come back to my point, if Docker or Kubernetes were invented today, I bet they would be using Rust or Zig instead of Go.
Java is fucking fast, I imagine Cliff Click would like a word with someone arguing golang outperforms a well-tuned JVM. But the language isn’t aging the best and interop with non-JVM languages is, also not the best.
golang seems pretty optimized for polyglot SOA-type setups where a comparatively modest amount of existing code compared to say C++ isn’t a real drawback because you’re hitting that stuff over the network anyways.
Rust is probably the better language in C++ niches at this point when you don’t have a big C++ ecosystem investment and can do a more “greenfield”-type project. That can become a holy war and I’ll leave my position at: “there are good reasons to choose both”.
In java (granted I haven't done java for a few years), you install the compiler/vm, and that is what you have. You have to decide if you are a maven or a gradle shop (and install these, or go bare lib/ mode), install and configure the said tools. When adding a dependency, you hope its on maven central, but sometimes its not, so random git repos are harder to try out/consume. Then eventually, you build your project and end up with a jar file, but you still have to manage its dependencies. You need the vm to run it, so you need to figure this out (jpackage also needs configuring in maven/gradle). You need your dependencies too, so you also need to figure this out (fatjar?).
Maybe things have gotten better in the recent years (and I'm happy to hear how), but my impression is still that the amount of dependency management you need to do with java far exceeds what you need to do in go.
Secondly anyone accessing Maven central directly is doing it wrong, the repo should be internal, validated by IT and legal, so for the consumers it doesn't matter how the JAR got there.
In a way it is ironic to see the whole containers/WebAssembly ecosystem redoing Java App Servers, 20 years later.
Once Loom&Co get merged, the JVM is going to be unrecognizable. It's also very possible that one of those Kotlin-native/GraalVM AOT projects goes mainstream. But right now it's a problem for high-performance systems.
Personally I regret this trend because Java/Golang are much easier for people like me than C++/Rust. I cannot imagine myself going back to manually managing memory. Browsing Big Data open source code will not be as educational anymore.
Likewise on the C++ side, someone has to write those constructor/destructor pairs, and there are ways to get RAII wrong.
Yes, you have to think about ownership. Because of single owner. But in general, not alloc/free. I work in Rust (after doing C++ for the 10ish years prior) full time and a couple nights ago was honestly the first time I had to really think about this (I had to do a 'forget' because I was passing a ptr to a vector back through from WebAssembly to our Rust-based runtime, and then clean it up back there instead of having Rust let it fall out of scope and free when the stack frame exited).
Think of Rust as a world where pretty much everything is inside a std::unique_ptr.
Most developers used to a GC language will have little problem working in Rust once they understand the single ownership model.
Async can be a pain, but you learn the ways. I work in a codebase with quite a bit of it.
There are appropriate and inappropriate places to apply Rust.
Yes, the compiler is - for almost all structs. I've been working with Rust since around 1.0 and I can count the number of times I manually had to write Drop implementations with my hands. Unless you are writing lower-level parts of the stack (which you rarely need to, since for many of those there are good crates already available) where you are responsible for resources that need a custom Drop implementation, the auto Drop implementation is good enough.
And for Rust standard library, where the Drop actually does something, someone else wrote the implementation for you.
It looks to me like the kind of librar(ies) that would normally be used as an internal aspect of a database or data analytics tools. Data containers / structures, data manipulation operators, and facilities for moving them around.
What this is is part of nice trend to open source some of the fundamental R&D that is happening inside the BigCorps.
Also, this kind of thing (and, indeed middleware as well) has been done in C++ by default inside Google (and probably Facebook as well) since forever.
C++ has gained a lot of affordances as well to improves safety as long as your can enforce their usage in the product so it's starting to eat into Java's market share as well. But I think long term Rust and Go will absorb more of what you would have done in Java than C++ will.