Coming back after a few years away from Haskell. What's changed?

#41

@sclv That sounds possibly very nice. It’s not widely known, I have never run into an example or a how-to demonstrating it, and I can’t easily detect it in the 3.8 or 3.10 release notes. To users, this means it effectively doesn’t exist of course. Documentation is one of the areas where cabal has not yet caught up to stack.

4 Likes
#42

Docs are here: 7. cabal.project Reference — Cabal 3.10.1.0 User's Guide

I know some users are making use of it, because we’ve had a number of tickets filed about it already :slight_smile:

1 Like
#43

So my person professional experience of the last few years is as follows:

  • we use stack, just because it’s “pin an LTS and you’re good to go” so for a beginning team it was less faff.
  • GHCup has made installation SO much easier and cleaner (thank you @hasufell)
  • HLS has been HUGELY beneficial in productivity.
    • unfortunately stack is a bit quirky when using HLS (files in test/bench folders don’t handle dependencies changing very well, so a bit more “Restart HLS” commands)
    • if you’re comfortable with cabal, I’d advise to use that for a better HLS experience
  • stack still has a few things that cabal doesn’t (like --no-rerun-tests) which are still a blocker for us to switch to cabal
  • We just updated to GHC 9.2 and are excited to be able to use record dot syntax and the non-moving garbage collector (yes, I know it was in 8.10 already, but I think I heard it’s more stable in the more recent versions of GHC)
  • The Haskell Foundation’s started making impact. (thank you @david-christiansen)
    • Better DevOps for GHC team (thank you @chreekat)
    • Bringing together some volunteer teams that think about certain aspects of the future of Haskell
    • There’s an error index now at https://errors.haskell.org/ !!! (albeit not comprehensive… yet)
  • We’re getting lots of (written) periodic updates on what’s happening wrt:
    • Dependent types
    • JavaScript / WASM backends
    • Core Libraries Committee proposals (thank you @ChShersh)
    • GHC DevOps
    • GHC development (I think mostly by Well-Typed? IOHK? Maybe another I’m forgetting?)

There’s bound to be stuff I’m still forgetting, but I’m super happy with where Haskell’s going at the moment :slight_smile:

12 Likes
#44

CLC proposals, I believe.

1 Like
#45

Ah, yes, apologies, I somehow keep mixing those up > .<

In my head they’re both under “That committee concerning the core parts of the language”

#46

I also feel like the improvements to HLS are the biggest change over the past few years. I do understand @maxigit 's point, too, though. If you asked me ~5 years ago what I’d hope for from a period of consolidation, the first thing is improved tooling, and we’ve had that with ghcup, HLS, and improvements to cabal. These are great changes, but our tooling is not so good that it makes a standalone argument for choosing Haskell over some other language. This work had to happen, and I’m thankful for it, but what of the package ecosystem?

I’d have hoped that streaming would be closer to settled, smoothing over the rifts between conduit, pipes, and other contenders, but that hasn’t really happened. For new code, you’ve got good options, but you’re likely to find something you’d like to use that will involve bridging between streaming libraries.

I’d have hoped that folks would rally around an approach to effects, as this is an area where Haskell is still more capable than most alternatives. This part of writing a new program always faces a big YAGNI question that I wish Haskell had a great answer for, something that lets you get started without any UX compromises made in the name of preventing bugs you can’t yet create. Maybe this can still happen, but it turns out we weren’t on the cusp of a decisive development.

As a reach, I had hopes that linear types would sweep over the core libraries like a wave, and we’d see more examples of programs with really tight memory usage. But, unsurprisingly, that change has proved to require a lot of work with not so many hands to do it.

Rust has undoubtedly absorbed some of Haskell’s excitement, in part by being so informed by Haskell, so this is not such a bad thing. I think Haskeller’s should absolutely try Rust. It’s great to use a compiler that works hard to help you, while also having access to an ecosystem benefitting from money and size. As for Haskell, it’s still the nicest place to write functional code, and with the improved tooling it has a much more modest barrier to entry.

7 Likes