A lot of these bullet points apply equally well in Haskell. Automatically derived JSON serialization from records, typed (and compose-able) SQL queries, whole-program feedback from the compiler; etc.
Especially the all-important advice: use Haskell when everyone on your team uses and wants to learn Haskell! Can't stress that enough. From experience, even when a language has all of the technical features to merit consideration for a project, what your developers are already familiar with will trump them all.
I wish it were a purely technical decision what language to use for a project but it's not. "Use the right tool for the job," is not the right advice for choosing a language. It's a social/network-effects type of decision.
Haskell doesn't have the documentation / doctest / code examples culture of Rust, cargo is arguably a better experience than any of the Haskell package management options (at least last time I checked) and I don't believe rust-analyzer is matched by anything in Haskell as a language server.
1000% this. Having worked in Haskell and having learned rust the past couple years. I love Haskell, but Rust really married a ton of the good parts of Haskell with a lot of "soft skill" elements that allowed it to graduate beyond being mostly a research language. It matters that in Rust I don't need to go read some blog posts about type theory if I want to make an API endpoint. It's not even that Haskell the language requires that, Haskell the culture requires that because there aren't (or at least weren't a few years ago) that many people promoting practical Haskell.
I haven't written more than a few pet projects in Haskell, but in my experience haskell-language-server is quite fantastic. I agree though that cargo has been a better experience for me, and while the documentation for Haskell is better than I would have expected, it certainly doesn't match up to rust.
Yes. About 2/3rds of the points rely on underlying language features of algebraic data types, type driven metaprogramming, and linear / affine types. Haskell has all of those, although linear types are still experimental. Scala has all of them apart from linear types (which have been explored at various times but are not officially part of the language.)
Haskell is cute until somebody in the team starts using the most advanced parts in some common task, destroying team's ability to understand what's going on and make changes; in a few years the author of such code will have the same problem (one's brain won't keep PhD-level capabilities the whole life). The same issue hit Scala development and led to complete rewrites back to Java or similar.
I would love to use Haskell. The main reason I stopped writing Haskell and started writing Rust was that I could more easily teach new programmers Rust due to better compiler error messages, and Cargo is 10000x easier to use than the Haskell package managers, which never seem to be able to resolve the right set of versions for me.
Being able to write a lot of functional Rust and drop down to imperative/mutation when necessary also eases the curve compared to Haskell.
I've written Haskell for 10+ years and I can honestly say that there are very few areas where I would seriously consider Haskell over Rust at this point. It also seems and feels like that is the general consensus at a lot of companies, many haskell shops having moved to using mainly rust, etc.
Everything in Haskell is an academic exercise with very little to show for it in the end. The performance is not that great, and even with "fearless concurrency", most complicated performance tuning situations are entirely consumed by understanding the intricacies of GHC Haskell and how to best tune your program by letting GHC abstractions leak into your code in the appropriate places to get it to run fast. People constantly keep reinventing streaming libraries because there are always problems or compromises, etc etc.
I really used to be on the haskell bandwagon for many years, but these days, when I reach for it, I end up really wondering why. Even the dev tooling is still bad, slow and buggy.
Social/network-effecst are critical part of the rigth tool, I read a blog about a companies who regret using rust becouse was impossible gey people whit experience in rust like the founders.
Especially the all-important advice: use Haskell when everyone on your team uses and wants to learn Haskell! Can't stress that enough. From experience, even when a language has all of the technical features to merit consideration for a project, what your developers are already familiar with will trump them all.
I wish it were a purely technical decision what language to use for a project but it's not. "Use the right tool for the job," is not the right advice for choosing a language. It's a social/network-effects type of decision.