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

22

OT but: suggestions are always welcome.

1 Like
23

Stack is in “maintenance” mode though and new features are not actively developed.

It also needs more love wrt HLS integration: Improve stack support for HLS · Issue #6154 · commercialhaskell/stack · GitHub

It lacks backpack support: Backpack for Stack · Issue #2540 · commercialhaskell/stack · GitHub

And more importantly lacks public sublibraries support: Support public sublibraries · Issue #5256 · commercialhaskell/stack · GitHub

While @mpilgrem is doing an excellent job of keeping the project alive, there definitely is a difference in active development between cabal and stack.

I personally like the stack codebase much more than cabals, but the net benefit of writing patches for cabal seems higher at the moment.

8 Likes
24

You clearly haven’t attended Zurihac then: https://youtu.be/DRFsodbxHQo

6 Likes
26

These past 3-4 years we’ve seen the rise of HLS, ghcup, and more generally a new era for our tooling.

9 Likes
28

I think your opinion is not very representitive. Tooling has been one of the major hurdles of Haskell adoption. Stack wasn’t written for fun. GHCup neither: it was written to unify installation methods across different platforms in a Haskell startup.

streamly is fairly new and quite revolutionary.

Did you miss the release of optics?

Lens with better error messages and more “strict” in some cases.

All in all I can’t really agree. Haskell has matured, so of course you won’t see the same amount of novel ideas floating around.

4 Likes
29

‘Exciting’ only takes you so far. I feel now we’re in a consolidation phase: not as exciting, but things are just getting more robust and more usable. If those years were dedicated to figuring out the amazing things Haskell lets you do, we’re now busy getting them and the language as mature as possible.

3 Likes
33

Welcome back :slight_smile:

There is a new immediate mode GUI library binding dear-imgui.hs.

The haskell-game community held a funny game jam named tiny-games-hs.

6 Likes
34

There have been many GHC changes not related to the record dot that you mention, you can read the Well-Typed activity reports to get a feel for them. Some highlights:

Of course there are also release notes and the GHC blog to peruse.

9 Likes
35

Could you provide a link detailing this? I can’t find anything anywhere.

1 Like
36

As someone who stepped away for a while, and is looking at it with fresh eyes, I find improved tooling and ergonomics very exciting. As I mentioned in the OP, I’m about to pitch Haskell to a new team, and making the developer experience with HLS, cabal, and ghcup just work like magic is huge.

I also think that 3-4 years is too short to judge whether a community has lost its ability to innovate. I think it’s reasonable to wait at least 5 for something groundbreaking to happen before giving up hope :slight_smile: Other languages are catching up, not because Haskell has stopped innovating, but because they were inspired by it.

Haskell is such a fertile environment to experiment with new ideas, and to my knowledge there isn’t any other language community where it’s even possible in the same way. There are other languages, but this community’s combination of dreamers and pragmatic developers trying to ship something is unique.

9 Likes
37

I don’t really understand most of these, but I’m so grateful that people are working hard on GHC and these problems. ARM64 support is immediately relatable though! I lost 3-4 days trying to compile a codebase in docker on an M1 mac.

2 Likes
38

That’s true. Solver-based install plans is a big one. And also vice versa: eg stack supports easy shared/maintained snapshot-based install plans, builtin or ghcup-integrated compiler installation, more windows support, --file-watch.

What’s the better HLS support about, do you know ? [Improve stack support for HLS · Issue #6154 · commercialhaskell/stack · GitHub I guess.]

3 Likes
39

I believe you @hasufell, thanks for the additional context. Cabal’s dev activity is certainly more visible (at least to me, as someone hanging out in #hackage). As a user, I haven’t noticed significant new features in either in the last year
(cabal release notes, stack release notes). It seems to be a lot of updating and fixing and cleanup (and I believe cabal has had more of that to catch up on).

40

This is actually one of the big changes in cabal-install recently – since 3.8, cabal-install allows project files to have imports, including remote imports, of other project/freeze/snapshot files – including, e.g. those provided by stackage.

(Further, these can be guarded behind conditionals per compiler-version).

5 Likes
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