If you look at rust now, I think it's a great example of keeping the _spirit_ but allowing to question just about any specific decision.
Funny that the "why not go" still stands, minus the "no generics" part.
On a different timeline, Rust reaching 1.0 before Go, I bet Docker and Kubernetes would have pivoted from Python/Java into Rust instead of Go.
I wonder, aren't there specific attributes of the Go language that makes it a particularly good fit for things like Docker/Kubernetes?
Easy to learn language and don't have to worry that much about memory, seen as a modern replacement of C in userspace, coroutines are easy to use and suit the lifecycle of network applications.
Compared to both Python and Java, no runtime or packages to fuss with, just builds one static exe
Java ecosystem is rather large, there have existed AOT compilers since around 2000, even if they had a price tag, and naturaly modern devs are allergic to pay for tools.
Those devs are now served with GraalVM and OpenJ9, as free beer AOT compilers for Java.
The only attribute of the language is hijacking Google's marketing to become relevant.
It's a terrible language, which has no practical reason to exist.
We would have to look at why Go was chosen over other languages, to make an assumption about that. Was it a technical decision, an emotional decision, or an expertise-based decision? In the latter two, you may be right.
If it was a echnical decision, it is not so likely. Go's heart is concurrency, while Rust's heart is memory safety. Wildly different.
Pure politics, on Kubernetes side, some Go folks joined the team and pushed for the rewrite for example, there is a FOSS talk on the matter.
Had not been the case, and most likely Kubernetes would have just been like Mesos, a mix of Java and C++.
Given its more ambitious goals and greater scope, Rust was always going to take a lot longer to mature than Go, so that there was no plausible chance of it reaching 1.0 before Go, if they started within a year or two of each other.
Except that on a different timeline really means Rust achieving 1.0 before Go, I didn't assert nothing else would have changed when they came to be in first place.
A different timeline is exactly that, a different line of events.