>the truth is when we needed super high performance in production, the answer was either Go or Rust.<p>For high performance, the answer is C, C++, Zig or Rust.<p>For backend it can be Go, it can be Java, it can be C#, it can be Python or Javascript.<p>C# is on par performance wise with Go and I suspect the same for Java.<p>Choosing a language for something has to be done by considering trade offs, benefits and disadvantages, on both long and short term.<p>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.<p>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.
The fact that Go is considered a “modern” language and nil pointer exceptions are downright common blows my mind every day. Is there a static checker config that folks use to reduce this risk? Because coming from a TS background it’s legitimately bizarre to me that at $COMP insufficient nil pointer checking <i>regularly</i> causes major production outages.
There's no real battle, except for language zealots.<p>Go gets a ton of things right for easy programming, and presents a super readable language with concurrency as a forethought.<p>Rust take a more conservative approach with a focus on correctness, and is the more performant language typically, for when you need it.<p>I don't at all see them filling the same niche, so I can't understand why this argument comes up so often.
There doesn't seem to be anything new here with Rust and Go that we already didn't know.<p>Reading the article, it looks like this article is generated by an LLM, as most things are nowadays.