[skynet-9000]

When I did enterprise sales, we had another phrase for that: "No one ever got fired for buying IBM." (Coincidentally, I also worked for IBM, back in the day.)

While it's true that tech choices are signals that enterprises do use to determine quality, if you are relying on a particular choice of programming language to sell into major enterprises that's simply a mistake. (And enterprises have invested vast sums in technology written in c# or PHP, so clearly it's not all "lol" out there.)

Rust's and Go's capabilities of compiling into a single binary, without requiring a JVM that needs to be fed and cared for, make them a particularly compelling choice for enterprise deployments. Kubernetes itself is written in Go.

[johnnycerberus]

Linux itself is written in C, though everything runs on it. Who cares about the language that Kubernetes is written in (by the way, it used to be Java but it was changed politically to Go)? If you are writing Java/Scala you can use GraalVM to achieve the same thing that Go does. If your service is mainly doing data processing, then Go won't help you there because its abstractions are too low-level or even non-existent. A Java service/app won't require a JVM if you you create a self-contained application package. Applications can be deployed on fresh systems with no requirement for the JRE to be installed. The advantage is that you control the version of the JRE used by the application and the disadvantage is that application updates are the responsibility of developer and self-contained applications do not have built-in support for automatic updates. Exactly why for services I wouldn't recommend it, and neither Go or Rust. I would never trade the state-of-the-art garbage collectors that the JVM provides me with the ones of Go or the borrow checker of Rust (though I would take Rust anytime over Go). I can't help myself but only think that you comment is straight from the 90s when it comes to the JVM ecosystem.