the truth is when we needed super high performance in production, the answer was either Go or Rust.
For high performance, the answer is C, C++, Zig or Rust.
For backend it can be Go, it can be Java, it can be C#, it can be Python or Javascript.
C# is on par performance wise with Go and I suspect the same for Java.
Choosing a language for something has to be done by considering trade offs, benefits and disadvantages, on both long and short term.
Rust would fit system programming while Go will fit the backend. I know "the right tool for the job" is very often mentioned but I will mention it again.
For backend I would be interested in a functional language, be it F#, OCaml, Elixir or Clojure, because I grew tired of OOP, SOLID, design patterns, clean coding, kingdom of nouns and Uncle Bob. All things, I used long ago to believe in. But since no one is hiring functional programming and I don't have the resources to be the sole owner and developer of a startup, I am stuck in kingdom of nouns.
I'm not sure either of those examples is true. For servers, Linux won, but that's just a fraction of OS usage. MySQL still has much higher usage rates than Postgres, particularly at massive scale, so calling that "won" is premature at best
In the backend you wait for databases, caches, external APIs and so on. Rust wouldn't be a major performance win over any strongly typed, compiled, garbage collected language. But it would mean lower development speed in a world where time to market is important.
If top raw performance was so important in the backend, people would have used C++ long before Rust became popular.
Now you might have a rare use case where raw performance is important, but in that case you write that part in a low level language and the rest of the microservices in a more productive one.
Comments
For high performance, the answer is C, C++, Zig or Rust.
For backend it can be Go, it can be Java, it can be C#, it can be Python or Javascript.
C# is on par performance wise with Go and I suspect the same for Java.
Choosing a language for something has to be done by considering trade offs, benefits and disadvantages, on both long and short term.
Rust would fit system programming while Go will fit the backend. I know "the right tool for the job" is very often mentioned but I will mention it again.
For backend I would be interested in a functional language, be it F#, OCaml, Elixir or Clojure, because I grew tired of OOP, SOLID, design patterns, clean coding, kingdom of nouns and Uncle Bob. All things, I used long ago to believe in. But since no one is hiring functional programming and I don't have the resources to be the sole owner and developer of a startup, I am stuck in kingdom of nouns.
For backend almost certainly the winner is Elixir. It’s been slept on for years.
It might be a winner but who is going to employ you to write Elixir?
I’ve been around long enough to see the underdog beat the well funded #1.
Linux beat Windows, PostgreSQL beat MySQL.
I'm not sure either of those examples is true. For servers, Linux won, but that's just a fraction of OS usage. MySQL still has much higher usage rates than Postgres, particularly at massive scale, so calling that "won" is premature at best
Rust might make sense on the backend, though the ecosystem isn’t great. (I’m still waiting for something matching the experience of FastAPI in Python)
In the backend you wait for databases, caches, external APIs and so on. Rust wouldn't be a major performance win over any strongly typed, compiled, garbage collected language. But it would mean lower development speed in a world where time to market is important.
If top raw performance was so important in the backend, people would have used C++ long before Rust became popular.
Now you might have a rare use case where raw performance is important, but in that case you write that part in a low level language and the rest of the microservices in a more productive one.