I don't think anyone is suggesting that Go should be like Rust. It's too late for that. We're suggesting that people should just use Rust (or Haskell, or F#, or any other robust functional programming language) instead.
Just because one person thinks Functional Programming is the right way to do it, doesn't mean another person has to agree. The same goes for every paradigm, and language feature under the sun. Different people want different things, different projects have different needs.
No single language gets everything right, no single paradigm solves every problem, no feature is a "must have" in every language. A functional approach might be great or a productivity killer depending on the use case. A GC may be the best thing in the world or a performance nightmare. OOP may be a really good idea or a path to unmaintainable crap depending on the implementation.
There are no silver bullets.
The only thing that is ABSOLUTELY certain: When people get told "Our way is better, you should use our way", despite the fact that there are no silver bullets, people will resist. And that resistance can lead to languages vanishing into obscurity.
> It's actually about what could kill Haskell, not what could kill Rust?
Here is the articles title: "What killed Haskell, could kill Rust, too"
So no, it's not about what could kill Haskell. In 2022, ~0.3% of all code pushed to github was Haskell. To put that number into perspective: vimscript was ~0.25%
Yes, I can read the title thanks. The article is about Haskell. The first sentence makes it clear it's speculative fiction presented as if from the year 2030. The article draws a hypothetical analogy between what could happen to Rust in 2030 and what is contemporaneously happening to Haskell.
And to return to the topic at hand, despite that article pointing to some weakness in the Haskell community, Haskell is thriving, so "We're suggesting that people should just use Rust (or Haskell, or F#, or any other robust functional programming language) instead" seems like reasonable advice to me.
And how well did that work out for Haskell?
https://gist.github.com/graninas/22ab535d2913311e47a742c70f1...
Just because one person thinks Functional Programming is the right way to do it, doesn't mean another person has to agree. The same goes for every paradigm, and language feature under the sun. Different people want different things, different projects have different needs.
No single language gets everything right, no single paradigm solves every problem, no feature is a "must have" in every language. A functional approach might be great or a productivity killer depending on the use case. A GC may be the best thing in the world or a performance nightmare. OOP may be a really good idea or a path to unmaintainable crap depending on the implementation.
There are no silver bullets.
The only thing that is ABSOLUTELY certain: When people get told "Our way is better, you should use our way", despite the fact that there are no silver bullets, people will resist. And that resistance can lead to languages vanishing into obscurity.