Welcome to the Functional Programming Zulip Chat Archive. You can join the chat here.
I'm soliciting feedback on my blog post: https://arifordsham.com/is-haskell-fast/
:thumbs_up: - it's to the point and informative
It may be interesting to point out that compared to popular languages, Haskell tends to make more use of immutable structures, which may have different performance characteristics - and related to that, zippers as a replacement for mutable pointers are actually pretty fast: https://arxiv.org/abs/1908.10926
And as you've mentioned, use of laziness in Haskell has it's problems too, in big part related to ecosystem.
Personally, after few years of using the language (and working in it) and talking to other Haskellers, if I were to decide whether Haskell should become fully strict, I would say no - not only it has important place in pure language for describing cyclic structures, but it allows for more data-driven approach to many problems - see dynamic programming, streaming, iterating (Rust can only replicate characteristics of our Data.List with complex hierarchy of wrappers), custom control flow operators or effortless combining of effectful operations.
But, while I think that laziness by default makes language more composable and elegant, I think that support for strict evaluation is just as important and that language should better nudge users towards it's use where applicable - not only by e.g. making behaviour of StrictData default, but too by having better support for unboxed datatypes - boxing strict data is usually just waste of space and time, while native unboxed types in GHC have limited support from libraries mostly related to low-level stuff. And even if using strict data was easier, all of that is useless without standard library that provides strict alternatives of general datatypes like e.g. tuples or lists.