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

#1

I’m starting a new project next week, and will likely be able to use Haskell. I’ve been doing other things for a few years, but prior to that I was using Haskell in production, writing Servant microservices, etc.

Catch me up! Here are some questions:

  1. What’s the modern way to build applications and fetch dependencies? Last time around I was using stack for everything (including getting ghc binaries). I know of ghcup, but does it do anything besides install binaries?

  2. What’s the latest in effects libraries? Any recommendations on where to look first?

  3. Is dot syntax working for updates yet? Last I checked, the record-dot-preprocessor worked well, but the GHC extensions required implementing HasField by hand for updates.

  4. Any other new developments I should be aware of?

Thanks!

6 Likes
Cabal Quickstart with HLS Pains
#2

I can help answer 1) and 4)

You’ve already mentioned it, but ghcup is now the way to go for managing your installation of ghc, cabal, stack, and hls. You can now have multiple versions of each installed on your computer, and with hls you can have vscode automatically detect and use ghcup to install and select the proper versions for your project. I used to have a whole nix setup that I used to control this for everything, but now I can just use ghcup + cabal because it has improved so much compared to the past.

Other less visible changes are the vastly improved support for ARM architectures, as well as the ongoing work on the JavaScript and wasm backends, and finally there is also the the new low-latency garbage collector which has made Haskell more suitable for real-time applications. All together, Haskell is usable in more places, in more ways than it ever has before.

2 Likes
#3

  1. ghcup for managing GHC and cabal in my experience works well.

  2. There were new developments in this regard with focus on practicality. Have a look at the effectful library, it solved most pressing issues of older libraries like poor performance and integration with the rest of the ecosystem.

  3. Sadly it doesn’t yet. But have a look at this tutorial, with the optics library and generic optics updating records is not a problem. And since GHC 9.2 and NoFieldSelectors extension the ugly prefix convention can finally be dropped.
    Btw, the note in the “Sample usage” section is somewhat outdated. I initially wrote it, but since then I switched from TH to generic optics in a quite large codebase and it turned out they’re fine, so I really need to change this note to be less scary. Implementation in the optics library is well optimized for compile time and run time performance.

4 Likes
#4

ghcup for installing your tools: ghc, stack, cabal and hls (even stack can rely in ghcup for instalation). Use cabal or stack for dependencies. cabal has overcome stack in popularity due to new nix-style builds. Both are good options.

I’d say effectful. But not very fan of effect systems right now

The extension -XOverloadedRecordDot allows for the use of struct.field. It defines HasField instances for you. -XOverloadedRecordUpdate is apparently very experimental and you need a few extensions to make it work

If you haven use hls; it is a good improvement in the last years.

3 Likes
#5

On (1): on top of what everyone else said, I want to emphasise that Cabal really is better than Stack now. As far as I’m aware, the latter is near-unmaintained.

On (4):

  • HLS is vastly improved. The IDE experience is much nicer than it was a few years ago. (And it works much better with Cabal than with Stack; another reason to switch!)

  • GHC recently had backends for JavaScript and WASM merged in — they’re at a primitive stage, but usable for some tasks, and rapidly improving.

  • The Haskell Foundation has made the Haskell community a lot more organised and focussed.

3 Likes
#6

Multiple recommendations for ghcup + cabal. Is this what you are referring to?. Are those v2* commands required?

If I just run cabal init and cabal build does it do a reproducible sandboxed build?

1 Like
#7

Are those v2* commands required?

Since cabal version 3 you don’t have to prefix with v2- (although you can). They’re the default. I guess the users guide is a bit out of date.

1 Like
#8

Yep, that’s the one. I’m really not sure why the documentation uses the v2 prefix: just cabal build etc. does exactly the same thing.

Not immediately, but cabal freeze makes it largely reproducible. Sandboxing hasn’t been needed for a long time now.

#9

I think maybe “sandbox” means something I didn’t intend in regards to cabal. What I meant to ask is: Can I run cabal build in multiple different projects on the same computer and not have them conflict?

1 Like
#10

Yes.

(and apparently without this parenthetical my post is too short for Discourse…)

2 Likes
#11

Can I run cabal build in multiple different projects on the same computer and not have them conflict?

Yes! It’s great :slight_smile:

1 Like
#12

I guess the users guide is a bit out of date.

Bug reported here: Quickstart guide refers to `v2-` commands · Issue #9086 · haskell/cabal · GitHub

3 Likes
#13

Amazing, thanks to all for explaining!

2 Likes
#14

What has changed is that a part from tooling nothing has really changed :frowning: .
We use to have people exploring new ideas (lens, servant, different form of effects ), that doesn’t seem to be the case anymore (lookes like some people have got kids or moved to Rust or both ).
There has been some work on dependent and linear types but nothing really helpful for “normal” haskellers.

The records problem is still a problem in spite of new extensions .

1 Like
#15

Well, a lot of things. For example, I finished the second edition of my important Functional Design and Architecture book in which I demonstrated a really pragmatic approach that is better than effect systems.

But Haskell is in the middle of the existential crisis at the moment. Most haskellers don’t agree with me on this but I see that Haskell loses the market constantly.

#16

Loses the market to what?

#17

I’m not quite sure what does it mean for an inanimate object to have an existential crisis.

As @chreekat coined elsewhere, it’s a Rorschach test which tells more about you than about Haskell. Let’s refrain from FUD, shall we?

12 Likes
#18

En garde, sir! I can’t agree with you on either point. A lot of online commenters seem to want these things to be true, but I think they must not be really looking. Eg:

stack commits in the last year:

image
image918×943 79.6 KB

cabal-install + Cabal commits in the last year:

image
image912×905 94 KB

stack releases in the last year:

cabal releases in the last year:

stack docs:

cabal docs:

stack dev community:

stack’s main community hub is its issue tracker I think (I’m not too sure).

cabal dev community:

The cabal project has been making excellent use of chat (#hackage), regular calls, etc. to build community.

8 Likes
#19

OK, point made. I’ve heard ‘near-unmaintained’ a few times recently; my bad for not verifying. Still, Cabal supports things that Stack doesn’t (e.g. backpack), and its HLS support is generally better (or at least it was last I looked).

#20

stack had its place around 2016 but nowadays it’s just a nicer CLI wrapper around cabal (which has a terrible CLI)

1 Like