Off the top of my head:
* Haskell language server solved the ide support problem
* Easy record access with . syntax (i.e. person.name to get a name off a person)
* A new {-# LANGUAGE GHC2021 #-} pragma that turns on a bunch of flags by default to write modern haskell
* GHCup to control installed haskell & tool versions
* Haskell foundation formed to support growing haskell
* A proposal* to work towards supporting dependent types was accepted
A lot more of course but it all points to making haskell more enjoyable to get into and use, and a good future ahead.
I've tried it since it was Haskell IDE Engine and only recently does it seem to "just work" without edgecase bugs (Template Haskell) or configuration
It's hard to take a language seriously that doesn't have a good IDE story.
I wrote a massive rant to Tom Ellis about why I thought writing Haskell was a terrible user experience and most of my complaints have been resolved in the last year or so.
But basically it's a meta-extension that flips on a bunch of extensions that most haskell users would come to expect as 'default'.
As a simple example: TupleSections. If the compiler complained to me that I needed to turn on TupleSections, I wouldn't take a minute to consider whether it was a good idea, I'd just be annoyed that I hadn't flipped it on somewhere already.
Actually that flag existing is part of why I think new books are being written, to start defining what "modern" (with all these flags on by default) haskell looks like.
I'm uncertain about Haskell ever becoming very popular. Rust seems to be sucking a lot of oxygen out of the room for new application programming languages, and Haskell is so old that I'd expect it to already be popular if it were ever going to become popular on its own merits. This doesn't matter much to me. There is enough manpower in the community to maintain the tooling and infrastructure, which keeps improving, and the language is fundamentally very very good.
I originally learned Haskell from the book Real World Haskell. It's probably dated now (the language and libraries have changed), but I would certainly welcome an updated second edition.
Hopefully someone finds the presentation interesting if they haven't seen it before :)
I wonder if a less lazy by default version of Haskell might have had any more success in the wider world. I know in the .NET world I've been burned more than a few times by the way Linq is lazy unless expressly realized (via methods like ToArray() and ToList())
I have however noticed that while much Haskell code doesn't make very fancy use of laziness, it is widely used for very local control flow. E.g. a pattern I see relatively often is `fromMaybe (error "...some message")`, which would be problematic in a strict language (because `error` would always be evaluated).
Even without partial functions, laziness can also simplify code structure when you can just 'let' bind any value that will possibly be used on any control flow path, without worrying about unnecessary computation.
These conveniences are not deal-breakers - I get by without them just fine in SML - but they do serve to make the language a bit nicer.
Although in your fromMaybe case couldn't you just have it generate short circuiting code under the hood instead of always evaluating? That isn't necessarily quite the same thing as laziness.
The beauty of functions like fromMaybe is they're only that - just plain, regular functions. No special casing under the hood required.
The essence of Haskell is non-strictness. It is the very reason Haskell was created.
There are already strict functional languages, like OCaml. What value comes from stripping Haskell of the soul of its existence?
I would highly recommend https://simonmar.github.io/pages/pcph.html regardless of which language you use day to day. It a treasure trove of excellent information.