Glad to see Simon Marlow didn't just vanish into Facebook.
qrobit•May 21, 2026
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.
this sounds like a nice non prescriptive direction. jose is a pretty cool dude. pre covid we theoretically were gonna poke a defining a memory model of ghc haskell c— / hs / core , but life intervened
benleejamin•May 21, 2026
How is the Haskell Foundation doing these days? Are we worried about its future?
cosmic_quanta•May 21, 2026
Chair of the HF here -- things are going quite well, actually. We have great sponsors who come back year after year, the HF has been spending more to make infrastructure more reliable (e.g. for Hackage), and we've started a new event series focused on North America (https://haskell.foundation/events/2026-amerihac.html), which has been a great success!
Our metrics are also showing that Haskell usage is actually growing. So overall, can't complain!
thecloudlet•May 21, 2026
Really like this language. I would love more if we can make developing production code easier.
shideneyu•May 21, 2026
I like it too. It's underrated because the learning curve is very high
thesz•May 21, 2026
The steepness of Haskell learning curve is exaggerated.
I have experience where completely unmotivated (due to then ongoing very bad divorce) former Java programmer took a description of CPU for model code generation in Haskell's eDSL and successfully extended it in a month. The model had tricky (at the time) type level programming and type classes with associated types.
mchaver•May 21, 2026
What do you find about bringing it into production? Is it the actual language patterns or the tools? I've done Haskell in production for over a decade now so I am not sure what challenges newcomers face.
cosmic_quanta•May 21, 2026
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?
thecloudlet•May 21, 2026
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.
satvikpendem•May 21, 2026
I heard of HVM recently, is that still related to Haskell or has that become its own thing?
bjoli•May 21, 2026
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?
satvikpendem•May 21, 2026
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.
faangguyindia•May 21, 2026
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
frogulis•May 21, 2026
> Deployment is pain specially on commodity VPS.
Oh? Why is that?
sshine•May 21, 2026
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.
isatty•May 21, 2026
You can use the GHC musl container: benz0li/ghc-musl:9.8.4 to create static binaries. I've specialized that into -arm64 and -amd64 containers for forgejo actions.
Anytime I push to my Haskell repos my actions automatically create static binaries for installation on my nodes.
internet_points•May 21, 2026
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
but does it require installing nix on mac? also many people are not familiar with nix and brew does all i need.
pianopatrick•May 21, 2026
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 not played around with it to see how that plays out with agentic coding. But it does seem like an interesting idea.
idle_zealot•May 21, 2026
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.
ShinTakuya•May 21, 2026
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.
the-grump•May 21, 2026
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.
mhitza•May 21, 2026
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.
Pay08•May 21, 2026
The package manager/build system is anything but decent. Any Haskell project will involve at least 24 hours worth of manual dependency conflict resolution.
nh2•May 21, 2026
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.
pjmlp•May 21, 2026
> - 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
holowoodman•May 21, 2026
> - the tooling is decades behind, say, Rust or Go
No way. Where vibe-coded Rust contains tons of "unsafe", you can have your vibe-coded Haskell sprinkled with "unsafePerformIO" and "unsafeCoerce" ;)
lmm•May 21, 2026
accursedUnutterablePerformIO or bust :)
jose_zap•May 21, 2026
> 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.
mirpa•May 21, 2026
Think problem is not in advanced features but in stability, integration and streamlining - compared to Rust/cargo.
drewfax•May 21, 2026
I tried building a cross platform shared library. I still couldn't get GHC to generate the library with Haskell's Runtime (RTS) statically linked. Tried multiple AI models and nothing could make it work. Eventually gave up after a month.
Also there's no support for Android and iOS, atleast not without spending months in recompiling GHC with haskell.nix or other third party projects.
Eventually I switched to Rust. It's tooling is so mature that I can focus on developing than compiling GHC.
Despite these demerits, I love Haskell language and lazy eval. I wish I can use it one day.
mietek•May 21, 2026
I built an example project showing how to build shared libraries in Haskell, in 2019.
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.
zozbot234•May 21, 2026
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.
rootnod3•May 21, 2026
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.
tome•May 21, 2026
Do GHC2021 and GHC2024 not do what you want?
uHuge•May 21, 2026
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.
isatty•May 21, 2026
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.
shideneyu•May 21, 2026
Much agreed
internet_points•May 21, 2026
There are lots of people successfully using agents with Haskell, for example
I can see how agent coding is a nice fit for Haskell, since LLM's tend to be best at tasks where you can easily verify the output – and GHC lets you easily verify much more of your domain than say Python (sure you can test some of what dynamic typing doesn't catch, but LLM-written tests do not always do what you think they should[0]). At the same time, the LLMs tend to not code golf unless asked to, and they don't care if they have to wait for dependencies to compile, so that takes away the two major Haskell time sinks.
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.
Paradigma11•May 21, 2026
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.
jappgar•May 21, 2026
"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.
thesz•May 21, 2026
I think you may find helpful this [1] almost 20 years old [2] agent.
The context window it requires for AI coding can be as short as half a dozen of tokens.
NexraGear•May 21, 2026
Nice to see continued investment in the Haskell ecosystem. Long-term sustainability for niche but highly influential programming languages is incredibly important for the broader software community.
shevy-java•May 21, 2026
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.
niek_pas•May 21, 2026
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.
haskman•May 21, 2026
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).
Jaxan•May 21, 2026
On the other hand, the language is already 35 years old and people still use it! Many other languages have died in the meantime.
KnuthIsGod•May 21, 2026
"The principal goal is to dedicate most of the Foundation’s financial resources to technical work.....
To make this possible, the Haskell Foundation will remain without an executive director for the foreseeable future.
Instead of having a full-time employee in charge of fundraising, events, coordination, mediation and much more, we will split these responsibilities between the Board and a new, part-time role dedicated to the Haskell Foundation’s financial sustainability."
Sounds a great move in principle.
mauvehaus•May 21, 2026
That only scales to a point. When there gets to be enough work, making it everyone's job ensures that it becomes nobody's job. Usually because one person was doing anyway in an informal capacity, and now they're overloaded.
Source, seen it play out in a non-technical nonprofit that after years of stagnation, went the other way of hiring executive staff to run the day to day stuff. And from currently being part of another organization that is flailing that way presently.
cosmic_quanta•May 21, 2026
Chair of the Haskell Foundation here -- funny to see this on the HN front page!
Not mentioned in the update is that the Haskell Foundation is moving towards a model that already exists within the OCaml Foundation. The HF and OF have the same challenge: a shallow pool of (relatively) large sponsors.
Of course big successful firms have more money to contribute, and we are thankful for them. This move, whereby the HF will deploy more of its financial resources on technical challenges directly, is meant to attract the other 99.9% of firms using Haskell in production. Many firms, including my own employer, have a more tit-for-tat view of sponsorship.
If you have thoughts, or would like to get involved, do not hesitate to reach out to me! E-mail in bio
11 Comments
He also reflected on his time and Haskell usage at Facebook here: https://www.youtube.com/watch?v=gEWBHP0PvRw&list=PLQpeDZt0_x...
Our metrics are also showing that Haskell usage is actually growing. So overall, can't complain!
I have experience where completely unmotivated (due to then ongoing very bad divorce) former Java programmer took a description of CPU for model code generation in Haskell's eDSL and successfully extended it in a month. The model had tricky (at the time) type level programming and type classes with associated types.
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?
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.
Are people targeting it as a runtime for Haskell as well?
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
Oh? Why is that?
Anytime I push to my Haskell repos my actions automatically create static binaries for installation on my nodes.
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...
I have not played around with it to see how that plays out with agentic coding. But it does seem like an interesting idea.
Compact syntax is generally only a good thing for LLMs because it saves context windows and tokens.
- 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.
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.
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.
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
No way. Where vibe-coded Rust contains tons of "unsafe", you can have your vibe-coded Haskell sprinkled with "unsafePerformIO" and "unsafeCoerce" ;)
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.
Also there's no support for Android and iOS, atleast not without spending months in recompiling GHC with haskell.nix or other third party projects.
Eventually I switched to Rust. It's tooling is so mature that I can focus on developing than compiling GHC.
Despite these demerits, I love Haskell language and lazy eval. I wish I can use it one day.
https://github.com/mietek/haskell-so-example
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.
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.
Even without AI most of my Haskell time is spent thinking.
Also, I hand writing Haskell is one of my small after work pleasures.
* https://github.com/digitallyinduced/ihp/ is mainly written with Claude now
* https://jappie.me/haskell-vibes.html is gushing over agent-written Haskell
* https://discourse.haskell.org/t/anti-llm-sentiment-considere... huge thread about the divisiveness of LLM's from some person who loves using them with Haskell
I can see how agent coding is a nice fit for Haskell, since LLM's tend to be best at tasks where you can easily verify the output – and GHC lets you easily verify much more of your domain than say Python (sure you can test some of what dynamic typing doesn't catch, but LLM-written tests do not always do what you think they should[0]). At the same time, the LLMs tend to not code golf unless asked to, and they don't care if they have to wait for dependencies to compile, so that takes away the two major Haskell time sinks.
[0] https://haskellforall.com/2026/05/type-out-the-code#:~:text=...
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.
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.
To make this possible, the Haskell Foundation will remain without an executive director for the foreseeable future.
Instead of having a full-time employee in charge of fundraising, events, coordination, mediation and much more, we will split these responsibilities between the Board and a new, part-time role dedicated to the Haskell Foundation’s financial sustainability."
Sounds a great move in principle.
Source, seen it play out in a non-technical nonprofit that after years of stagnation, went the other way of hiring executive staff to run the day to day stuff. And from currently being part of another organization that is flailing that way presently.
Not mentioned in the update is that the Haskell Foundation is moving towards a model that already exists within the OCaml Foundation. The HF and OF have the same challenge: a shallow pool of (relatively) large sponsors.
Of course big successful firms have more money to contribute, and we are thankful for them. This move, whereby the HF will deploy more of its financial resources on technical challenges directly, is meant to attract the other 99.9% of firms using Haskell in production. Many firms, including my own employer, have a more tit-for-tat view of sponsorship.
If you have thoughts, or would like to get involved, do not hesitate to reach out to me! E-mail in bio