That’s not entirely true, though… Stack has its own methods of managing packages, which makes it different to Cabal in what you can easily do (e.g. global stack build <library> is easy).
2 Likes
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
You clearly haven’t attended Zurihac then: Alexis King on "Delimited Continuations, Demystified" @ZuriHac2023 - YouTube
6 Likes
Sorry, when I said new I mean new exciting packages that everybody was talking about.
10-15 years ago, the Haskell world was exciting, things were happening.
For example (not in chronological order)
- the lens package was released. It was incredible , not that I’m using it but it was revolutionary.
Everybody (in the r/haskell at least) was talking about it. I think SJP said something along the line (correct if I am wrong) “I even didn’t know this was possible in Haskell”. People were playing with the concept trying to push the limit - You had the Conduit/Pipe war (should I said competition). Those package solved a concrete streaming in novel and efficient way. People built lots of packages on top of that.
- Servant arrive, it was also revolutionary. It seems the way to do Routing (even though I think the honey moon is over now)
- In the mean time, Stack arrives forcing Cabal to step up is game.
- You’ve got Generic which was a way of doing meta programming without using Template Haskell.
- Esqueletto sort of set the standards to do type safe Sql querying
- Then Free things arrived leading to Free Monad and starting “effect” movement.
I’m not saying that people have stopped working and publishing academic paper but in the last 3-4 years I haven’t seen anything exciting.
3 Likes
These past 3-4 years we’ve seen the rise of HLS, ghcup, and more generally a new era for our tooling.
9 Likes
Fair enough, but all those tools solve problem that I don’t really have, therefore I don’t find them exciting. For people who do find them useful , it is merely catching up with the level of tooling seen in other language/ide. "We are nearly as good as X " is not really a selling point.
1 Like
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
‘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
Fair enough. So my answer to “what has changed?” is "we have enterend the Consolidation era ".
1 Like
So the most revolutionary packages in the last few year are a rehash of existing packages ?
If so, that is my point.
1 Like
Tooling has been one of the major hurdles of Haskell adoption
I agree with you. But I have already adopting Haskell and solved for my own use the tooling problems which I think is the case of most people who use Haskell in production.
I am not saying those tools are useless, and that people working on it are wasting their time. In the contrary. But I don’t count it as exciting because it so far it doesn’t provide featuren not seen anywhere else (except maybe filling hole with djinn). People like me who found workaround are happy with there workaround. People discovering Haskell expect those things and are just complaining about how painfull it is to setup compare to X.
Welcome back 
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
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:
- Improved C++ support motivated by text-2 which uses C++. Btw text-2 switches internal representation of text from UTF-16 to UTF-8
- New Windows IO manager. See Tamar Christina - The new Windows I/O manager
- Old build system removed in GHC 9.6. Now only the new build system is available, Hadrian. See make-to-hadrian
- HIE files coming to a GHC near you (does “few years” include 4 years?). I believe this provides the some technical underpinnings for HLS that people have mentioned.
- A new Native Code Generator for ARM64. This is still getting fixed up now, see Feb-Mar 2023 report. ARM64 also prompted a recommendation to use capi imports.
Of course there are also release notes and the GHC blog to peruse.
9 Likes
Could you provide a link detailing this? I can’t find anything anywhere.
1 Like
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 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
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
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
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).
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