[ghc-steering-committee] GHC2023

[Simon Marlow]

On Mon, 24 Oct 2022 at 20:49, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Does anyone have any insight from the real world?


Yes!


> Has GHC2021 helped
> our users? And if not, why not?
>

Not a bit, because we're still using GHC 8.8 :-)

Having said that, at work we've been using our own version of GHC2021 for
many years now (by just enabling a set of extensions by default in the
build system) and I'm often reminded how much time it saves.

I'm somewhat persuaded by the people on the discourse thread arguing that
if the point is stability, then we should not produce new iterations too
frequently. But what is too frequent?

Cheers
Simon




>
> What kind of hard data would you like to see, if any?
>
> (I’m a bit wary of spending too much time writing scripts to scrape
> hackage, for example to see which extensions people tend to enable _in
> addition_ to GHC2021, only to see that libraries on hackage are
> understandably slow to use default-language: GHC2021, as that’s not
> great for backward compat for now. But I am also not sure where to look
> for good data…)
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20221104/895f8fbb/attachment.html>