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

11–20 of 81 posts

Re: Haskell Foundation 2026 Update

#11

Post by the-grump »

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 with the correct algebra. Again models can probably learn to create the right types and orient the solution around that, but it's not automatic

- same today as yesterday, laziness is a blessing and a curse. The runtime can do unpredictable things when you suddenly evaluate a deep thunk

- GHC directives effectively mean there are multiple "Haskells"

Some of those are a result of the "avoid success at all costs" mantra. You can't shake that off in a day. It will take a concerted effort to make it more amenable for seamless adoption.

Haskell continues to be my favorite language to write and read, but Rust is the more practical language with a rich type system. If you're looking for something approaching Haskell's expressiveness but with fewer of these issues, check out PureScript.

Re: Haskell Foundation 2026 Update

#13

Post by qrobit »

chowells wrote: post #2

Glad to see Simon Marlow didn't just vanish into Facebook.

He doesn't have a role at Facebook anymore AFAIK, although I can't find the source now. I remember hearing it was mostly due to filtering engine at Facebook being rewritten in Hack, so they don't have the need for Haskell people anymore.

Re: Haskell Foundation 2026 Update

#14

Post by uHuge »

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…

Yup, it was mostly pleasure AI coding a company codebase in Scala. I'm considering it for next projects for this reason although my understanding and intuition for Scala code is much weaker than for Python.

Re: Haskell Foundation 2026 Update

#15

Post by frogulis »

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

> Deployment is pain specially on commodity VPS.

Oh? Why is that?

Re: Haskell Foundation 2026 Update

#16

Post by mhitza »

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…

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 function, wrapper types when stacking monads, and import fiddling.

Re: Haskell Foundation 2026 Update

#17

Post by sshine »

frogulis wrote: post #15
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

> Deployment is pain specially on commodity VPS. Oh? Why is that?

I can only think of memory usage during compilation. That’s why I had to precompile binaries, which means cross-compile. Then if you add cross-OS, bundling a properly linked or statically linked binary is not that easy.

Re: Haskell Foundation 2026 Update

#18

Post by psittacus »

qrobit wrote: post #13
chowells wrote: post #2

Glad to see Simon Marlow didn't just vanish into Facebook.

He doesn't have a role at Facebook anymore AFAIK, although I can't find the source now. I remember hearing it was mostly due to filtering engine at Facebook being rewritten in Hack, so they don't have the need for Haskell people anymore.

He posted about him leaving Facebook on Linkedin: https://www.linkedin.com/feed/update/urn:li:activity:7302785...

He also reflected on his time and Haskell usage at Facebook here: https://www.youtube.com/watch?v=gEWBHP0PvRw&list=PLQpeDZt0_x...

Re: Haskell Foundation 2026 Update

#19

Post by isatty »

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 an intermediate Haskell programmer, I’ve found that using AI to debug or learn Haskell is a better use of time than generating a lot of code with it.

Even without AI most of my Haskell time is spent thinking.

Also, I hand writing Haskell is one of my small after work pleasures.

Re: Haskell Foundation 2026 Update

#20

Post by pjmlp »

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

If only Rust had something like GHCi.

Stack and Cabal have longer history than cargo, and Stackage for puzzle dependencies.

> - GHC directives effectively mean there are multiple "Haskells"

A bit like macro libraries and what features are enabled where in Rust

Post reply on HN