The difference is between pervasive laziness (laziness by default) v/s laziness by opt-in. If you have laziness by opt-in, then most parts of the language will

The difference is between pervasive laziness (laziness by default) v/s laziness by opt-in. If you have laziness by opt-in, then most parts of the language will not opt-in [from prior experience with, say, racket which also has lazy streams]. It's the pervasive and efficient compilation of laziness in Haskell which makes it actually useful to write lazy programs. Now, am I a fan of writing lazy programs? No, I find the upshot of referential transparency gained by laziness to be overshadowed by the warts it brings --- lack of a good debugging experience, tie-the-knot semantics being fragile, etc. I'd rather live in a strict total programming language. But one cannot "handwave" away laziness in haskell that easily by saying "you can emulate it in $STRICT_LANGUAGE". By the exact symmetric argument, one can emulate strict code inside haskell: just use `ST` or `IO`. But very rarely does one see whole libraries written strictly, because this style of code doesn't compose with the (default) laziness and purity in haskell.