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

31–40 of 81 posts

Re: Haskell Foundation 2026 Update

#31

Post by instig007 »

internet_points wrote: post #24
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

Cross compilation could definitely be easier :-/ I tend to just use github actions and compile from whatever architecture it should run on, so that's a workaround. I long for a day when I can just `cabal build --platform=amd64` etc. and it Just Works without having to download and compile a horde of foreign libs or set up a vm

> cabal build --platform=amd64

It's almost a one-liner + a nix derivation import, works within a minute on incremental builds even on large projects: https://input-output-hk.github.io/haskell.nix/tutorials/cros...

Re: Haskell Foundation 2026 Update

#32

Post by Pay08 »

mhitza wrote: post #16
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…

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.

Re: Haskell Foundation 2026 Update

#33

Post by ShinTakuya »

idle_zealot wrote: post #10
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 suspect that the compact nature of the syntax would require more tokens spent "thinking" to get decent results. It might be more efficient for simple code though. Either way worth testing. Surely someone must've set up a "how well LLMs handle Xlang" benchmark suite.

I think the main reason more time might be spent thinking is because there's relatively less training data on Haskell out in the wild, meaning an agent may have to check back and forth with static analysis to figure out what's valid.

Compact syntax is generally only a good thing for LLMs because it saves context windows and tokens.

Re: Haskell Foundation 2026 Update

#34

Post by nh2 »

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.

No, this is not the reality of using Haskell packages.

The problem you describe was solved more than a decade ago.

You use a Stackage snapshot (https://www.stackage.org/lts) which is a curation of packages that work together, similar to a Linux distribution like Debian, carrying one version per package.

Our company using Haskell has not spent 1 minute doing "dependency resolution" in the last 10 years, not has anybody we know.

Re: Haskell Foundation 2026 Update

#35

Post by haskman »

niek_pas wrote: post #29
shevy-java wrote: post #26

I found Haskell too difficult. They focus on a specific niche, so they won't be a mainstay programming language anyway, but even then when you ask people what are the real innovations or success stories per given year, say, 2025 or 2026, they almost never mention Haskell.

I don't mean to sound elitist, but in a way, Haskell's difficulty is kind of the point of the language. The thing that's so elegant about Haskell is that it allows you to express programmatic constructs at a very abstract level. Abstraction is almost by definition difficult to grasp. That's why it takes a decade and a half for (most) people to go from arithmetic to calculus.

Difficulty is most certainly not the point. Abstraction, composability, yes, but difficulty is a language smell that CAN be fixed. (I love Haskell and it's my primary langauge, so this comes from a place of love).

Re: Haskell Foundation 2026 Update

#36

Post by angled »

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 was a little disappointed with the results I was seeing in F#. I thought the .NET + GPT-5.* pull through would be sufficient but it never seemed to work out. Maybe I just wasn’t approaching it correctly.

Re: Haskell Foundation 2026 Update

#37

Post by jose_zap »

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, say, Rust or Go

That's definitely not true, even if that was true maybe 6 years ago. As someone who's uses Haskell daily and also many other languages, I can see Haskell's tooling as more advanced than many others.

Re: Haskell Foundation 2026 Update

#38

Post by onlyrealcuzzo »

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, 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 language for LLMs because I think expressiveness is key.

Re: Haskell Foundation 2026 Update

#39

Post by jappgar »

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…

"no global state" sure but sprawling monad constraints mean you're jumping around more than other languages.

The terseness of Haskell just hides the inherent complexity of the problem. The AI (or human) still needs to uncover that complexity in order to do non-trivial things.

Re: Haskell Foundation 2026 Update

#40

Post by zozbot234 »

onlyrealcuzzo wrote: post #38
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…

> 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.
Post reply on HN