GHC 9.4.1 is now available | Hacker News Reader

GHC 9.4.1 is now available

discourse.haskell.org

113 pointstodsacerdoti48 comments

\cases is a nice syntax improvement https://github.com/ghc-proposals/ghc-proposals/blob/master/p...

    \foo bar baz -> case (foo, bar, baz) of
      (Just 4, 3, False) -> 42
      _ -> 0
    
    -- becomes
    
    \cases
      (Just 4) 3 False -> 42
      _ _ _ ->

---

    extremelyLengthyFunctionIdentifier (Just a) False = Just 42
    extremelyLengthyFunctionIdentifier (Just a) True  = Just (a / 2)
    extremelyLengthyFunctionIdentifier _        _     = Nothing

    -- becomes
    
    extremelyLengthyFunctionIdentifier = \cases
      (Just a) False -> Just 42
      (Just a) True  -> Just (a / 2)
      _        _     -> Nothing

Thanks to reintroduction of deep subsumption we could finally update IHP to the GHC 9 series. So really happy about the recent GHC releases :)

If you're curious about Haskell, IHP is a good starting point (https://ihp.digitallyinduced.com/ https://github.com/digitallyinduced/ihp). IHP is Haskell's version of Laravel/Rails/Django. It's really a superpower to have Haskell's type system combined with the rapid development approach of Rails :) (Disclaimer: I'm founder of the company that makes IHP)

Has there been a recent surge in Haskell popularity? I noticed Pragmatic Programmers and Manning are both working on new books about Haskell, which is the first time in ages I can recall a significant publisher announcing Haskell books, though I may have missed some in the meantime.

Hard to say if it's gotten more popular (yet), but development speed has picked up and some longstanding things have been fixed. A lot of things in the ecosystem have improved as well. It feels like it's all moving again, and to a place it could start gaining popularity.

Off the top of my head:

* Haskell language server solved the ide support problem

* Easy record access with . syntax (i.e. person.name to get a name off a person)

* A new {-# LANGUAGE GHC2021 #-} pragma that turns on a bunch of flags by default to write modern haskell

* GHCup to control installed haskell & tool versions

* Haskell foundation formed to support growing haskell

* A proposal* to work towards supporting dependent types was accepted

A lot more of course but it all points to making haskell more enjoyable to get into and use, and a good future ahead.

* https://github.com/ghc-proposals/ghc-proposals/pull/378

I'd say that HLS finally starting to mostly work is the single biggest driver

I've tried it since it was Haskell IDE Engine and only recently does it seem to "just work" without edgecase bugs (Template Haskell) or configuration

It's hard to take a language seriously that doesn't have a good IDE story.

I wrote a massive rant to Tom Ellis about why I thought writing Haskell was a terrible user experience and most of my complaints have been resolved in the last year or so.

What a detailed answer, thank you for so many specifics. I bounced off Haskell last time I tried it but seeing all this is certainly exciting and I'll have to keep an eye on it.

Do you have any links to, or can you share any more information about "modern" haskell? What's different?

More info on the extension they referenced here: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/cont...

But basically it's a meta-extension that flips on a bunch of extensions that most haskell users would come to expect as 'default'.

As a simple example: TupleSections. If the compiler complained to me that I needed to turn on TupleSections, I wouldn't take a minute to consider whether it was a good idea, I'd just be annoyed that I hadn't flipped it on somewhere already.

Pretty much what rrradical said. I haven't seen any articles around "writing code with only haskell 2010 vs GHC2021", but now that we have a baseline in the community things like that could be written.

Actually that flag existing is part of why I think new books are being written, to start defining what "modern" (with all these flags on by default) haskell looks like.

As a language, I think it was always good. Haskell is my main working language, so I tend to mostly see the warts, but whenever I have to use another language I end up feeling very constricted. Haskell does have some very real warts, but I would say that for example the current state of the tooling is only bad when compared to the very best (e.g. cargo is arguably better than cabal, but cabal is better than what a lot of other languages have).

I'm uncertain about Haskell ever becoming very popular. Rust seems to be sucking a lot of oxygen out of the room for new application programming languages, and Haskell is so old that I'd expect it to already be popular if it were ever going to become popular on its own merits. This doesn't matter much to me. There is enough manpower in the community to maintain the tooling and infrastructure, which keeps improving, and the language is fundamentally very very good.

I originally learned Haskell from the book Real World Haskell. It's probably dated now (the language and libraries have changed), but I would certainly welcome an updated second edition.

Putting Rust and Haskell in the same category always puzzles me a bit: I’d think Rust is more in the same category as C++?

Yes, Rust as a language wasn't originally intended for much of what it's used for now. Many of the applications written in Rust would probably be fine without the borrow checker, and instead paying a performance overhead to have GC. I think Rust is succeeding on the strength of its tooling and the overall relative modernity of the language (e.g. proper sum types and sane metaprogramming). Of course, Haskell has these things too, although some of the incarnations may be a bit more crufty (Rust macros seem a lot more accepted than Template Haskell does).

Rust was absolutely intended for systems programming from the start, it’s just that the “you can drop the GC but still have memory safety” bit wasn’t there at the beginning. Safe systems programming was the goal from the beginning.

http://venge.net/graydon/talks/intro-talk-2.pdf

I am aware. My post was about Rust not originally being intended for much of the non-concurrent and performance-agnostic application programming it is currently being used for (e.g. the enormous amount of CLI utilities cropping up). Its popularity in this domain is due to qualities that were not part of (or at least orthogonal to) the original vision.

Ah, I see, my bad. I misunderstood. (I think part of it is also like, what even is "systems" is confusing; I think many folks would think of those CLI apps as being bread and butter systems stuff, but you can slice it both ways really.)

Hopefully someone finds the presentation interesting if they haven't seen it before :)

One thing that can really mess with people as well is how much of Haskell is (or was last I played with it) lazy by default. Some things like infinite lists where you only take a subset obviously have to be lazy, but in other cases the way it messed with memory usage could be incredibly confusing.

I wonder if a less lazy by default version of Haskell might have had any more success in the wider world. I know in the .NET world I've been burned more than a few times by the way Linq is lazy unless expressly realized (via methods like ToArray() and ToList())

Yes, the next Haskell will be strict; that's generally although not universally accepted.

I have however noticed that while much Haskell code doesn't make very fancy use of laziness, it is widely used for very local control flow. E.g. a pattern I see relatively often is `fromMaybe (error "...some message")`, which would be problematic in a strict language (because `error` would always be evaluated).

Even without partial functions, laziness can also simplify code structure when you can just 'let' bind any value that will possibly be used on any control flow path, without worrying about unnecessary computation.

These conveniences are not deal-breakers - I get by without them just fine in SML - but they do serve to make the language a bit nicer.

Perhaps there could exist a middle ground for cases where it does not risk significant "random" memory bloat and similar issues. I 100% think there are edge cases where laziness has value.

Although in your fromMaybe case couldn't you just have it generate short circuiting code under the hood instead of always evaluating? That isn't necessarily quite the same thing as laziness.

Short circuiting is a special case of laziness. It's local only, so no thunks are required.

The beauty of functions like fromMaybe is they're only that - just plain, regular functions. No special casing under the hood required.

> Yes, the next Haskell will be strict; that's generally although not universally accepted.

The essence of Haskell is non-strictness. It is the very reason Haskell was created.

There are already strict functional languages, like OCaml. What value comes from stripping Haskell of the soul of its existence?

I agree that the lower-level details of Rust and the original vision for it was not super close to Haskell, but having said that, I think it often attracts a lot of the same people. Rust traits are very similar to Haskell's typeclasses, and stuff like the Iterator API and the fact that mutability is a first-class concept in the language (and therefore easy to keep track of if you want to avoid it) make it pretty well-suited to functional programming. Add that to the fact that developer productivity is valued pretty highly, which is why there's such a focus on good tooling e.g. cargo, compiler errors, and you end up with a language that does a surprisingly good impression of "Haskell but more user friendly". There's a bunch of other stuff too, like the ability to "drop down" into imperative programming, and the fact that you can use references and stuff to avoid allocations, but if you want to just take everything by value and clone everything without using `Arc` or `Rc` and go pure functional, Rust isn't going to get much in your way.

Haskell developers want Haskell to be fast and safe. Rust is fast and safe.

Yeah Haskell always seemed interesting, I just never got my head around it on the couple attempts I made. Mostly surprised because languages as old as Haskell rarely see potential at another surge in popularity when they have been around this long unless something (library/framework/etc) comes along and makes people reevaluate them.

I'm thinking it may be due to functional programming ideas slowly being introduced to (or were already part of) some of the more trendy/mainstream languages like C++20 (ranges, lambdas, concurrency, etc) & Rust (pattern matching, immutability, etc). Haskell always seems to pop up when discussing these topics lately, which made me more interested than I was previously. I intend to (attempt to) start learning Haskell in the near future, so I'm glad that there's new books being written on the subject.

A fair few of the features coming from functional languages are also available in OCaml though I feel like I haven't seen quite the same surge there. And in cases like Rust and F# MLs were the inspiration for how they built their functional feature sets as far as I know.

Facebook's been developing and promoting their Reason ML dialect

How much do they promote it? I feel like I rarely hear about Reason, but I might simply be looking in the wrong places.

I think it probably gets more promotion than OCaml. But yeah, it's definitely not on the same level as eg. React or something; I get the sense there's a faction in the company that owns it and really cares about it but maybe doesn't get as much priority from the top as some other groups

I think ReasonML is no longer maintained by facebook

Don't forget about Javascript! I wouldn't be surprised if React and Redux and new-ish JS features like `map`, `reduce`, etc. have contributed significantly as well.

I still don't know a better language for parallelism. Some alternatives can make up for being sluggish by employing parallelism. Haskell is already reasonably efficient (for my problems) and parallelism is trivial to add.

This is oft overlooked, Haskell is absolutely in a league of its own when it comes to concurrency and parallel capabilities.

I would highly recommend https://simonmar.github.io/pages/pcph.html regardless of which language you use day to day. It a treasure trove of excellent information.

I assume crypto has been a fairly big part of it too, a number of chains use Haskell and Cardanos smart contract language is a Haskell library.

Maybe time to give haskell another try. Last time (5 years ago?), I got stuck on two issues:

1. Wasn't clear on environment/toolchain and ended up compiling for a long time just to install one package. Pretty sure I was doing it the wrong way but saw inconsistent information about what to do. I'm almost sure this is fixed by now, or at least enough for me to stop complaining about it.

2. The runtime seemed more annoying than I'm accustomed to. I remember trying to load some haskell code into another program, and it was modifying the signal handlers, which was totally unacceptable for my use case so I gave up. This is an area rust is much better.

3. It was difficult to use ghci-like functionality from another program (compile bits of haskell code). Maybe it's more library-like now and I can just use ghci now? Neither rust nor haskell is great here.

> 1. Wasn't clear on environment/toolchain and ended up compiling for a long time just to install one package. Pretty sure I was doing it the wrong way but saw inconsistent information about what to do. I'm almost sure this is fixed by now, or at least enough for me to stop complaining about it.

This can still happen. Unless you use Nix (don't do this unless you already like Nix), there is no distribution of precompiled Haskell packages. Some "framework"-like packages recommended to beginners may depend on a huge number of other packages.

> 2. The runtime seemed more annoying than I'm accustomed to. I remember trying to load some haskell code into another program, and it was modifying the signal handlers, which was totally unacceptable for my use case so I gave up. This is an area rust is much better.

It is still annoying. Haskell will definitely hijack your signal handlers. It needs them to handle timers, to handle garbage collection, and maybe do other things in the concurrent IO system. I'm not aware of any work to make it collaborate with other signal handling shenanigans, but I haven't looked. I doubt it is possible; Unix signal handlers really are not a good foundation for modular design.

> 3. It was difficult to use ghci-like functionality from another program (compile bits of haskell code). Maybe it's more library-like now and I can just use ghci now? Neither rust nor haskell is great here.

This is most likely easier. GHC has become much more friendly to library use.

Shameless plug: https://tontine.com are hiring Haskellers to roll out their provably secure lifetime income pensions which are now endorsed by the OECD.

> We would like to thank ... the Zw3rk stake pool

Interesting, is this a blockchain proof of stake/work system where the work done is running a CI for GHC?

Technically it’s running a proof-of-stake stake pool and using the operational rewards to fund CI hardware for GHC. It currently provides 7 Linux, 2 windows and 3 m1 macs as well as covers the maintenance for them.

Thus by staking ada (cardano) with the stake pool, one can “earn” a competitive rate (~4%) of stake return as well as support GHCs CI indirectly as the excess operational rewards from running the pool are put towards running CI machines for GHC.

To compare this to some non-blockchain scenario:

Depositing money at a bank will yield some interest, but also provide the bank with some operational return (they usually don’t provide you a savings account due to altruistic reasons); and the operational rewards the bank would use to run CI machines for GHC.

I hope this makes sense, and explains the concept of how this works in principle.

Ok, thanks for explaining.

I got excited for a moment and thought that the compilation was being used instead of hashing as a proof of work. That would require compilation to be trivially verifiable though, so sadly it is not the case.

Looks like it

https://reddit.com/r/haskell/comments/ls0p18/experiment_can_...

That is so cool! I've long imagined something like this for static site generators where the work is to render and verify content.

I don't think it works as you think it works...

The non-blockchain equivalent of this would be: "If you are buying stuff on Rakuten please use "Zw3rk" as referrer code! I promise I'll spend all money earned by referrals on servers for GHC CI"

So yes, technically this is a blockchain system which supports GHC CI... but practically it is all traditional hardware and regular cash after the first step.

Stackage should focus more on 9.x GHC, for now the latest LTS is 9.0.x-based version.

Stack looks to be on life-support right now : https://discourse.haskell.org/t/answered-is-stack-still-acti...

In other news, Cabal 3.8 supports stackage snapshots kinda: https://discourse.haskell.org/t/just-released-cabal-3-8-1-0/...

Not too long ago I tried getting Haskell Language Server, GHC, Cabal, Stack, etc. to play nice together in Neovim but didn't have much luck. Has anyone else here had luck with Neovim + Haskell?

Yes! For me it was a great plug and play experience.

I’m using coc.nvim[1] as my LSP client. It works really great with HLS. Maybe you can give it a try?

[1]: https://github.com/neoclide/coc.nvim

I don't know how to get debugging to work. Do you know?

Not yet but I'm going to try and crib from https://github.com/ocharles/dot-files/blob/master/nvim/init.... when I have some time to waste.

Reply on news.ycombinator.com