[HN Gopher] GHC 9.4.1 is now available
___________________________________________________________________
GHC 9.4.1 is now available
Author : todsacerdoti
Score : 108 points
Date : 2022-08-12 10:53 UTC (12 hours ago)
(HTM) web link (discourse.haskell.org)
(TXT) w3m dump (discourse.haskell.org)
| runevault wrote:
| 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.
| Athas wrote:
| 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.
| massysett wrote:
| 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++?
| Athas wrote:
| 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).
| runevault wrote:
| 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())
| Athas wrote:
| 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.
| massysett wrote:
| > 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?
| runevault wrote:
| 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.
| mibsl wrote:
| 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.
| steveklabnik wrote:
| 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
| Athas wrote:
| 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.
| steveklabnik wrote:
| 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 :)
| saghm wrote:
| 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.
| runevault wrote:
| 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.
| Syzygies wrote:
| 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.
| eklavya wrote:
| 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.
| bontaq wrote:
| 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
| gavinray wrote:
| 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.
| rychco wrote:
| Do you have any links to, or can you share any more
| information about "modern" haskell? What's different?
| rrradical wrote:
| More info on the extension they referenced here: https://gh
| c.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.
| runevault wrote:
| 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.
| EddySchauHai wrote:
| 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.
| rychco wrote:
| 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.
| runevault wrote:
| 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.
| brundolf wrote:
| Facebook's been developing and promoting their Reason ML
| dialect
| runevault wrote:
| How much do they promote it? I feel like I rarely hear
| about Reason, but I might simply be looking in the wrong
| places.
| brundolf wrote:
| 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
| ChadNauseam wrote:
| I think ReasonML is no longer maintained by facebook
| niek_pas wrote:
| 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.
| rundmc wrote:
| Shameless plug: https://tontine.com are hiring Haskellers to roll
| out their provably secure lifetime income pensions which are now
| endorsed by the OECD.
| _zachs wrote:
| 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?
| kasbah wrote:
| 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.
| ivmoreau wrote:
| 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
| platz wrote:
| \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
| xvilka wrote:
| Stackage should focus more on 9.x GHC, for now the latest LTS is
| 9.0.x-based version.
| cosmic_quanta wrote:
| 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/...
| _query wrote:
| 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)
| chmod600 wrote:
| 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.
| Athas wrote:
| > 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.
| steeleduncan wrote:
| > 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?
| angerman wrote:
| 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.
| steeleduncan wrote:
| 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.
| jaipilot747 wrote:
| Looks like it
|
| https://reddit.com/r/haskell/comments/ls0p18/experiment_can_...
| [deleted]
| [deleted]
| encryptluks2 wrote:
| That is so cool! I've long imagined something like this for
| static site generators where the work is to render and verify
| content.
| theamk wrote:
| 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.
___________________________________________________________________
(page generated 2022-08-12 23:02 UTC)