I wrote a bit about this here: https://news.ycombinator.com/item?id=31663316 https://news.ycombinator.com/item?id=31663316 In brief, I think Haskell is still t

I wrote a bit about this here: https://news.ycombinator.com/item?id=31663316 https://news.ycombinator.com/item?id=31663316 In brief, I think Haskell is still the purest expression of what makes it great. This is both a good thing, for the reasons I outlined there, and a bad thing, because e.g. stringing together a few iterator methods in Rust may be a functional style but it still prepares you for the concepts you'll encounter in Haskell about as well as zooming a Hot Wheels around on the kitchen floor prepares you to drive a lap in an F1 car without stalling out or flying off the track. People with a modern imperative background know this intuitively---or maybe they just assume it, and happen to be correct---as soon as they look at a page of nontrivial Haskell code. One thing people seem to miss about laziness in Haskell is that it's (unfortunately?) really tightly coupled with how "control structures" are expressed. For instance, instead of writing a loop with some infinite or indefinite condition, you might declare a list using a generator function and iterate over its values. I would like to see how other similar languages (e.g. Purescript) have done away with it, and how it impacts them. But my recollection from when I actually knew Haskell is that it was an incredibly powerful feature tightly integrated with the language design, not only from a data perspective but also from a perspective of allowing code structures to map much more closely onto the data structures they're manipulating. (This is a big part of why, as I think I mentioned somewhere else in this thread, Haskell is so ergonomically suited for working with tree-like linked data structures.)