Stack and HLS, questions about the present and future

[george.fst]

Frankly, IMO, Stack is dying. Usage has been dropping dramatically since Cabal added “Nix-style builds” in 2019 (unfortunately it’s been two years since the last Haskell Survey but anecdotally it seems the trend has continued). The original developers of Stack have since disappeared and the project has largely lost its momentum, and I just don’t think the community has the bandwidth to support both tools well (although @mpilgrem has been doing a lot of thankless work to keep the lights on!).

Hate to ask the question, but I wonder at what point Stack should stop being suggested by default to new users, e.g. on the downloads page…

I think this has to happen eventually, since the current situation is confusing for beginners and Stack now has few benefits and a lot of drawbacks. But it’ll take a few years, since, as @hasufell says, Cabal is yet to fully eclipse Stack in functionality. Plus, there’s a lot of politics and historical baggage surrounding all this and no one wants to reopen those wounds.

[simonmic]

Usage has been dropping dramatically since Cabal added “Nix-style builds” in 2019

I guess you say this based on the surveys ? Please break it down for us, what data makes you think this ?

The original developers of Stack have since disappeared and the project has largely lost its momentum

Or: stack has been successfully handed off to a new more active lead maintainer, it has gained an active chat room like cabal’s, and Releases · commercialhaskell/stack · GitHub is looking pretty busy ? (Cf cabal-install releases)

[george.fst]

I guess you say this based on the surveys ? Please break it down for us, what data makes you think this ?

To be honest, anecdotes (colleagues across multiple companies, discussions on here and at Zurihac etc…). But looking at the surveys now: we have “Stack is used by more than twice as many people as Cabal” in 2017, Cabal overtaking it narrowly in 2021, then building a 36% lead by 2022.

[george.fst]

@simonmic

stack has been successfully handed off to a new more active lead maintainer

Okay, fair enough, I had seriously underestimated how actively developed Stack is, so kudos to @mpilgrem for that! Still, I’m not sure it changes my overall impression that Stack will become redundant eventually, and that the most important thing is to continue with the relatively small steps required to achieve parity in Cabal.

[jmct]

Just a quick thing to add here as well:

Lots of university courses use stack for their course projects. I know of at least 3 very large courses (totaling over 1k students per year) that require stack. Those sorts of users are often under-represented, since only a handful of them go on to become members of the Haskell open source community.

[hasufell]

@george.fst

Okay, fair enough, I had seriously underestimated how actively developed Stack is, so kudos to @mpilgrem for that!

I don’t understand where this impression comes from. I think stack is more active now than before? Maybe it doesn’t have those big fix-all PRs from Snoyman and co or fancy blog posts with grandiose visions. But development is pretty steady.

For getting big things done, it relies on contributors more than before. E.g. Component-based builds · Issue #6356 · commercialhaskell/stack · GitHub

Although I’ve only really contributed significantly once, the process was shockingly fast. Something I can’t say about cabal, where I have a hard time getting a proper decision out of the dev team.

@george.fst

and that the most important thing is to continue with the relatively small steps required to achieve parity in Cabal

I had to chuckle, because those “small” steps involve things like fixing --help, which is a humongous task, because there’s some shared logic between cabal-install and Cabal the library.

So it’s definitely not just feature parity.

[chreekat]

For me, one of the main takeaways here is the centrality of HLS. @ktf (sweet profile pic btw) says, “[A]s a newcomer to Haskell I was playing with individual .hs files with the help of HLS long before I started a real ‘project’”. That’s a crucial insight for Haskell tool developers. Haskell grew up in the days of running build tools from the command line, but those are specialized tools these days.

[ktf]

@chreekat

@ktf (sweet profile pic btw)

Thanks!

@chreekat

For me, one of the main takeaways here is the centrality of HLS.

@chreekat

Haskell grew up in the days of running build tools from the command line, but those are specialized tools these days.

To expand a bit, if it’s helpful, my own progression looked something like: 0) Install everything with GHCup, 1) Mess around in GHCi a little bit, 2) Start working through beginner tutorials/books/small problems, all of which used small, single-source-file programs (HLS was still a huge help in this step!), and finally 3) Start a “real” project using Stack (though still small toy projects, initially).

So I didn’t actually touch Stack until I had built several small programs and worked through most of Get Programming in Haskell. (Which, incidentally, I loved.)

@simonmic

Which project/team do you think should do that testing and documentation work, ideally ?

@simonmic

PS, maybe you could list the specific problems you’re hitting in your usage ? That would be useful.

Getting back to documenting the Stack+HLS issues and their various workarounds… it’s a small thing, but to start with I’ve added a section to my big ol’ Notes of a Haskell Beginner doc. Far cry from official docs – these notes are mostly for my own consumption – but I do share them out if I think there’s stuff in there that’ll be helpful to other beginners.

That said, I still don’t have a 100%-works-all-the-time solution, or even a definitive set of specific symptoms of the problem

[simonmic]

Great notes, thank you! (I have read only the HLS part).

One I think you haven’t mentioned: when doing Restart Haskell LSP server, do it while viewing a source file in the component you want to work with. That’ll make HLS prioritise/work best with that component.

More generally yes I know how chaotic it can feel when you see weird new error-of-the-day and none of the usual workarounds seem to help. To reliably fix HLS issues I think you really have to carefully study the Tasks > Haskell log and diagnose the underlying problem (or get the HLS room to do that for you).

[ktf]

@ktf

The confusing bit for me is that the page doesn’t make it clear that there’s a decision point there. The implication is that both Stack and Cabal are required. And the descriptions don’t clarify much: “tool for managing Haskell software” vs “program for developing Haskell projects”.

Sorry to quote myself, but as another anecdotal data point, I just came across this recent post on Reddit: “Stack and Cabal, do they do same thing or different ?” At least I’m not the only one

@simonmic

One I think you haven’t mentioned: when doing Restart Haskell LSP server, do it while viewing a source file in the component you want to work with. That’ll make HLS prioritise/work best with that component.

Good point! I feel like that’s naturally how this dance tends to play out – the file you’re trying to work on is “broken”, so you restart while you’re in that file – but good to be explicit about that.

@simonmic

To reliably fix HLS issues I think you really have to carefully study the Tasks > Haskell log and diagnose the underlying problem (or get the HLS room to do that for you).

Definitely. I fully accept that no LSP experience is going to be perfect, and I don’t mind getting my hands dirty. In fact, I’m proud to say that I’ve had a couple of my own HLS bugfixes merged! (Albeit small ones.)

To me though, the issues with Stack and HLS are persistent and disruptive enough to warrant more visibility than they’ve got.