I was also thinking of conwayâs law, but for opposite reasons! I really donât think the standardized vs implementation barrier is what stands in the way of addressing cross-cutting concerns. Its not causation, but mutual correlation. If you have one (funded) team seeking to develop a successful language, then you will get a tooling and support ecosystem that is integrated as part of a single effort. If you have different groups working on the compiler, the editor support, the build system, etc. then you will naturally get OS-level process boundaries as a way to enforce modularity between the various components of the respective teams. Also, it so happens that if you have one funded team seeking to develop a successful language you will tend to get an implementation-defined language, because that is the default and only in some fairly rare cases is there enough compelling reason to drive a standardization process to fully take place.
(And typically that happens best once a language is âsettledâ â i.e. when there is not a core team trying to drive it forward any more).
There are plenty of mainly implementation defined languages that have none of the tooling benefits we see from the integrated structure of racket or rust â e.g., python, perl, ruby, etc!
To be really provocative about it, Iâd even pose that the evolution of Racket has been somewhat ret-conned. It was not first a language that came along with a development environment. Rather, it was first an IDE for scheme, that grew an integrated ecosystem to such a degree that it eventually became a language!
A group of volunteers can just start backporting things into ghc-8.10 branch of GHC. If they make significant progress and maintain required level of quality, I imagine it should be possible to make more releases in 8.10 series. This is magnitudes less effort than forking a compiler, and still I do not believe it will ever happen.
âŚyes: trying to find such a group of volunteers that havenât already grown tired of constantly chasing after the âinnovation infernoâ that GHC has turned into would be difficult. Itâs probably easier for them to e.g. just grab the âplus-sizedâ copy of Hugs, make the necessary changes, build and install it instead (most likely for their own personal use) - 75% of the features for 75% less hassleâŚ
But who knows: in the future, those HLS devs, also thoroughly-fatigued with the status quo, may choose to first build the HLI (Haskell Language Interpreter), to investigate the potential for developing their own compiler.
The fact that Hugs was happily left to R.I.P. many years ago without much attempt to resuscitate suggests that your estimate of âinnovation infernoâ of GHC is very much wrong.
I believe improvements to RTS are quite orthogonal to surface language features (also in terms of GHC codebase), so I donât see a problem with backporting them.
But GHC devs might know more.
My very personal estimate of GHCâs innovation: the only feature of value since Hugs was left (late 2006) is Pattern Synonyms - and even those I think the idea is promising, but the detailed implementation is unfriendly to those declaring Synonyms.
There were plenty of innovations as of 2006 that were left half-finished or even withdrawn: FunDeps, Overlapping Instances, pre-1999 Datatype Contexts, TREX â which purescript has implemented more-or-less.
I agree with the distaste expressed above for GHC 9.0 onwards: of course performance improvements are always valuable; the âfeaturesâ are just making GHCâs syntax too hard to keep up with. Iâm no longer even trying.
At work we are very happy after upgrading to 9.2. The upgrade was not difficult and we only saw benefits.
I would not like to live without RecordDot again.
The negativity against 9.2 puzzles me.
I guess there are three kinds of people: Those who happily use 9.2, those who are working on upgrading to it, and those who gave up and spend more time on the forums 
You forgot (at least) three other kinds of people:
-
Those who think Haskell has ended up a being language for âpropeller/egg headsâ or âelitistsâ and have quietly gone elsewhere;
-
Those who are no longer interested in the âbusy-workâ of rewriting legacy code to keep up with the latest
fadsâinnovationsâ from Glasgow Haskell Central and have quietly gone elsewhere; -
Those who have seen other single-implementation languages arrive and depart:
[âŚ] since the compiler was written in LML [with only one implementation remaining] it was more or less doomed to dwindle.
âŚand are understandably cautious about being too dependent on another one: Haskell.
-
(âŚthere are probably others;-)
If that was true, why would Hugs be abandoned since 2006? If your longing for Hugs was not just a sweet nostalgia, someone would keep the lights on.
âŚactually, some people still do (even if it is just essential maintenance). And who knows what could happen when the second Rust compiler arrives:
At least Hugs is written in a standardised language with at least two major implementations ;-)
Sorry, but even Miranda gets more updates
Miranda(R), like Erlang, is a language with âcommercial backingâ rather than just being sponsored (to varying levels).
But itâs nice to know itâs still getting some attention after all these decades⌠:-)
(âŚwait: what language is Miranda(R) implemented in again?)
Miranda(R), like Erlang, is a language with âcommercial backingâ rather than just being sponsored [link to Haskell Foundation website] (to varying levels).
âjust being sponsoredâ is also a weird way to say âhas over $500k/year in funding from commercial backersâ.
Haskell is financially backed. There are multiple companies that add features to GHC constantly, including:
- Well-Typed (backed by Hasura, IOG, etc.) has at least 6 employees that commit to GHC often from a cursory look
- A bunch of companies funded HLS and donated employee hours
- IOG is merging GHCJS upstream
- Tweag has done a whole bunch of stuff on GHC
- Serokell funds a bunch of work on GHC
- The list goes on: Obsidian, Meta, MercuryâŚ
âŚand they could all [potentially] drop all that funding just as easily e.g. if some âhot newâ language appeared that they thought would be a better investment than Glasgow Haskell.
So yes: âjust being sponsoredâ - if they really were interested in the future of Haskell beyond âthe Glasgow dialectâ, at least one of them would now have started work on an alternative Haskell implementation, like Embecosm and Open Source Security have been doing for the last two years with Rust.
Performance regression is another reason not to update to newer ghc versions:
https://gitlab.haskell.org/ghc/ghc/-/issues/22338
https://gitlab.haskell.org/ghc/ghc/-/issues/22373
How many of those companies have full time employees working on GHC? I believe itâs essentially one.
I hope youâre aware that upgrading GHC poses real challenges for big companies (like meta) and I donât think they spend much time on the forums.