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

51–60 of 81 posts

Re: Haskell Foundation 2026 Update

#51

Post by rootnod3 »

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…

I think the GHC directives are what hurts Haskell the most. At this point they should just embrace the GHC extensions and make it the "official" Haskell.

Having to enable them in the code is just a hassle. Just make it official and be done with it, just roll it into the language.

Re: Haskell Foundation 2026 Update

#52

Post by tome »

rootnod3 wrote: post #51
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…

I think the GHC directives are what hurts Haskell the most. At this point they should just embrace the GHC extensions and make it the "official" Haskell. Having to enable them in the code is just a hassle. Just make it official and be done with it, just roll it into the language.

Do GHC2021 and GHC2024 not do what you want?

Re: Haskell Foundation 2026 Update

#53

Post by satvikpendem »

bjoli wrote: post #7
satvikpendem wrote: post #6

I heard of HVM recently, is that still related to Haskell or has that become its own thing?

It is just a runtime, no? I have only ever heard about it as something to run their own bend programming language. Are people targeting it as a runtime for Haskell as well?

I looked into it more, several years ago it was for Haskell specifically and then they created the bend language as I guess Haskell was not up to their needs and use cases.

Re: Haskell Foundation 2026 Update

#54

Post by faangguyindia »

instig007 wrote: post #31
internet_points wrote: post #24

Earlier quoted context omitted.

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...

but does it require installing nix on mac? also many people are not familiar with nix and brew does all i need.

Re: Haskell Foundation 2026 Update

#55

Post by thecloudlet »

cosmic_quanta wrote: post #46
thecloudlet wrote: post #5

Really like this language. I would love more if we can make developing production code easier.

We're always happy to hear about pain points! For example, one thing that is a friction point at my own job is knowledge of tooling for performance tuning and optimization. It's not that Haskell doesn't have this tooling, it's just not well-known. Is there anything in particular you would need?

I think the greatest problem is documentation. I work on compilers daily. Sometimes I am forced to read directly in to Ghc’s code to just use as a developer.

Maybe we should use Ai to generate up-to-date docs that are well organized like a book, so that all devs are more easy to conquer the different tools and flows.

For example, in C++, for basic toolchains LSP, formatters, standards of formatting, guidelines for performance, do and don’ts, … are more accessible.

I know it’s partially because of the size of the community. If we find a way to make the beginners, or experienced dev from other languages easier to start writing production code. We can thrive more.

Re: Haskell Foundation 2026 Update

#56

Post by Paradigma11 »

angled wrote: post #36
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.

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.

Re: Haskell Foundation 2026 Update

#57

Post by Jaxan »

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.

On the other hand, the language is already 35 years old and people still use it! Many other languages have died in the meantime.

Re: Haskell Foundation 2026 Update

#58

Post by Paradigma11 »

Paradigma11 wrote: post #56
angled wrote: post #36

Earlier quoted context omitted.

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.

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.

Re: Haskell Foundation 2026 Update

#59

Post by pianopatrick »

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 haven't seen such a benchmark although maybe it exists.

As far as benchmarks go, I'd also like to see benchmarks that try to find what LLMs are good at. Most of the benchmarks seem designed to give LLMs hard problems and see if they can succeed. In that sense a "good" benchmark is one with a low pass rate.

But if we're going to do agentic coding we also need to know the opposite. We need to know which types of tasks given in which format LLMs will succeed at with like 95%+ accuracy. Then we can more easily build multi prompt pipelines with high confidence in each step.

Re: Haskell Foundation 2026 Update

#60

Post by the-grump »

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…

That's a fair question. It's part ecosystem, part tooling. The ghcup, stack, cabal mishmash is closer to maven than a tool with a modern streamlined UI like cargo.

And yes, Haskell is significantly more expressive than Rust--at the cost of performance.

Post reply on HN