Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haskell Foundation 2026 Update

discourse.haskell.org

Post reply on HN
Print view View original

71–80 of 81 posts

Re: Haskell Foundation 2026 Update

#71

Post by xedrac »

whateveracct wrote: post #70
the-grump wrote: post #11

Earlier quoted context omitted.

As someone who loves Haskell more than any other language, some challenges are - the tooling is decades behind, say, Rust or Go - finding the right library in looks very different in Haskell--you frequently start with the signature on Hoogle. Agents can learn this but it's not the same as "web search" - creating the right solution also looks different. It's usually borne out of thinking about the types and coming up…

cabal is as cargo-level but has a bad CLI. it really isn't that bad. and Haskell has amazing Nix support. Like 3 different good options there depending on your project. and this isn't even to mention stack.. now, if you're a not smart enough to handle there being many options existing in a world of trade-offs..haskell was never for you :)

[dead]

Re: Haskell Foundation 2026 Update

#72

Post by rootnod3 »

whateveracct wrote: post #70
the-grump wrote: post #11

Earlier quoted context omitted.

As someone who loves Haskell more than any other language, some challenges are - the tooling is decades behind, say, Rust or Go - finding the right library in looks very different in Haskell--you frequently start with the signature on Hoogle. Agents can learn this but it's not the same as "web search" - creating the right solution also looks different. It's usually borne out of thinking about the types and coming up…

cabal is as cargo-level but has a bad CLI. it really isn't that bad. and Haskell has amazing Nix support. Like 3 different good options there depending on your project. and this isn't even to mention stack.. now, if you're a not smart enough to handle there being many options existing in a world of trade-offs..haskell was never for you :)

"haskell user smart". Condescend much?

And Haskell baking itself to Nix, also not sure if that is a good option. Try compiling that on say OpenBSD or FreeBSD.

Re: Haskell Foundation 2026 Update

#73

Post by pjmlp »

zozbot234 wrote: post #40
onlyrealcuzzo wrote: post #38

Earlier quoted context omitted.

> the tooling is decades behind, say, Rust or Go Can AI not help speed this up? As someone who DOESN'T use Haskell... What specifically is it missing? Are you conflating ecosystem with tooling? > If you're looking for something approaching Haskell's expressiveness but with fewer of these issues, check out PureScript Rust is quite expressive. Is Haskell really substantially much more? I do think Rust is a great langua…

Haskell is more easily compared with e.g. OCaml than with something like Rust. (It's worth noting that OCaml now has its own 'rustified' development OxCaml.) The main practical difference is that Haskell is idiomatically based on lazy evaluation, whereas OCaml is strict. This makes corecursive patterns a bit easier to express in Haskell, but OCaml and OxCaml are friendlier wrt. performance concerns.

Just as Haskell with Linear Haskell.

Re: Haskell Foundation 2026 Update

#74

Post by pjmlp »

faangguyindia wrote: post #8

Developer exercise is still lacking in Haskell ecosystem. Slow build times, deployment to Linux when developing on macos still pain. Deployment is pain specially on commodity VPS. Go is very easy to cross compile and deploy. But Haskell is better for a few things, but I've hardtime deploying it

GHCi exists, embrace the REPL.

Re: Haskell Foundation 2026 Update

#75

Post by epolanski »

pianopatrick wrote: post #9

The thought crosses my mind that Haskell may be uniquely suited for AI coding using a very small context window (cheap). Haskell encourages small functions and no global state. So you may be able to capture all the relevant context for editing a Haskell function within a few hundred or few thousand tokens. That would be better than some other languages. Plus the strong typing could help AI agents catch errors. I have…

I had a good experience extending the Elm compiler, written in Haskell.

AI did very good with it (both Opus 4.5 and GPT 5.4). It has a good time reasoning on compiler feedback and iterating for the reasons you mention.

But I still don't like Haskell and lisps for the very same reason: they don't scale.

Every single project out there needs to reinvent the wheel at language level (in form of compiler extensions or DSLs).

Makes the whole ecosystem hard to contribute and leverage.

People can keep saying how great lisps or Haskell are all they want, but the fact remains that very ugly languages everybody hates somehow can produce software so good that makes you adopting the language bearable.

There isn't a single software that makes me (personally) go "yeah, I want to learn Clojure/Racket/Haskell so I can use X".

Whereas stuff like Laravel or Rails or Redis or Unreal Engine can sell me on PHP, Ruby, C/Lua, C++ even though I'm not particularly fond of any of those languages.

Re: Haskell Foundation 2026 Update

#76

Post by whateveracct »

rootnod3 wrote: post #72
whateveracct wrote: post #70

Earlier quoted context omitted.

cabal is as cargo-level but has a bad CLI. it really isn't that bad. and Haskell has amazing Nix support. Like 3 different good options there depending on your project. and this isn't even to mention stack.. now, if you're a not smart enough to handle there being many options existing in a world of trade-offs..haskell was never for you :)

"haskell user smart". Condescend much? And Haskell baking itself to Nix, also not sure if that is a good option. Try compiling that on say OpenBSD or FreeBSD.

Haskell doesn't bake itself to Nix at all. Nix just happens to have multiple pretty mature and usable libraries for packaging Haskell.

Re: Haskell Foundation 2026 Update

#77

Post by alper »

the-grump wrote: post #11
pianopatrick wrote: post #9

The thought crosses my mind that Haskell may be uniquely suited for AI coding using a very small context window (cheap). Haskell encourages small functions and no global state. So you may be able to capture all the relevant context for editing a Haskell function within a few hundred or few thousand tokens. That would be better than some other languages. Plus the strong typing could help AI agents catch errors. I have…

As someone who loves Haskell more than any other language, some challenges are - the tooling is decades behind, say, Rust or Go - finding the right library in looks very different in Haskell--you frequently start with the signature on Hoogle. Agents can learn this but it's not the same as "web search" - creating the right solution also looks different. It's usually borne out of thinking about the types and coming up…

> the tooling is decades behind

For all the academic interest the language has, it seems very few of those people want to do anything foundational to make the language more ergonomic and more relevant.

Re: Haskell Foundation 2026 Update

#78

Post by simonmic »

epolanski wrote: post #75
pianopatrick wrote: post #9

The thought crosses my mind that Haskell may be uniquely suited for AI coding using a very small context window (cheap). Haskell encourages small functions and no global state. So you may be able to capture all the relevant context for editing a Haskell function within a few hundred or few thousand tokens. That would be better than some other languages. Plus the strong typing could help AI agents catch errors. I have…

I had a good experience extending the Elm compiler, written in Haskell. AI did very good with it (both Opus 4.5 and GPT 5.4). It has a good time reasoning on compiler feedback and iterating for the reasons you mention. But I still don't like Haskell and lisps for the very same reason: they don't scale. Every single project out there needs to reinvent the wheel at language level (in form of compiler extensions or DSLs…

I didn't understand what you meant by "haskell and lisp don't scale". Are you saying their library ecosystems are weak ?

Re: Haskell Foundation 2026 Update

#79

Post by angled »

Paradigma11 wrote: post #58
Paradigma11 wrote: post #56

Earlier quoted context omitted.

I am using https://github.com/github/spec-kit and am pretty content. I also tell it in the constitution.md to generate the .fsi files first, then write tests for it before implementation. That might very well be useless superstition since it is soo easy to fool yourself.

Also tell it to prefer easy language constructs with a need to justify anything more complex. I am currently trying to add elmish since its mind numbingly boring explicit plumbing is something I no longer have to do.

Thanks, I will try that!

Re: Haskell Foundation 2026 Update

#80

Post by zeendo »

Pay08 wrote: post #32
mhitza wrote: post #16

Earlier quoted context omitted.

No way tooling is decades behind. You have a decent LSP, debugger, package manager and REPL. Laziness is hard to observe, maybe Strict and StrictData would become more popular in use within this context. I haven't checked in a while now if effects have become the norm in the ecosystem, or if some solution exists for "string" types, but for me all of Haskell's expressivity is lost in the noise of endless conversion fu…

The package manager/build system is anything but decent. Any Haskell project will involve at least 24 hours worth of manual dependency conflict resolution.

Pretty dishonest take. The most gracious read on this is that you encountered this situation ages ago and assume it's still the case today.

I've been writing Haskell in production for almost 10 years now and manual dependency resolution has never been a thing.

Post reply on HN