I was thinking of Haskell recently, why isn't it more popular with AI? Haskell is very terse and token efficient, it has many expressive safety features. Rust is getting additional adoption because of its strictness, so hey why not have this in Rust over Javascript if it takes the same time to write?

An ideal language for agentic AI I would think is extremely strict, where the AI can iterate over the tooling for correctness. It would probably be less verbose and more terse to allow the AI to be more efficient with tokens.

It's my default for all the reasons you mention.

In fact if I have to ship in a different language, I'll often do a Haskell version first to steer towards isolating IO, enforcing referential transparency, and generally picking up other functional patterns that are a good idea no matter what. Then I'll port the Haskell version to whatever the solution demands.

I do AI research and mostly work with Lean these days. I love Haskell, though I wouldn't consider myself a particularly strong Haskell programmer (just never spent a ton of time working in it). I think you're spiritually correct that there are lots of reasons to use extremely strict languages with AI, but the reality is a little messier than you'd expect.

Token efficiency is specifically the place where strict languages get a little trickier. With dynamic languages where the model has a ton of training data, like Python, the agents are really good at writing code that just works. You still have challenges there, but they're just different than the challenges you hit with a language like Haskell/Lean/Agda etc. With Lean, for example, the amount of things the agent decides it needs to prove for a relatively trivial operation can lead to an absurd amount of code. And the way it decides to prove them can be borderline labyrinthian. It sort of plays perfectly towards current agent weaknesses, where agents can run off and reinvent a lot of machinery and build unnecessarily complex abstractions.

And those iterations have a cost. Even if the final artifact is more terse, the path to getting there can involve a huge amount of backtracking and rewriting and off-by-one syntactic corrections.

Ultimately, a lot of this comes down to developer experience. Getting useful error messages for the agent, having fast compile times so that the agent can iterate quickly, providing useful utilities for debugging, etc. There was a popular blog post specifically about Haskell that generally makes this point--the Haskell language is, in a vacuum, ideal in a lot of ways for AI, but the Haskell developer experience and ecosystem made it hard for this team to build with it via agents: https://avi.press/posts/2026-07-10-after-7-years-in-producti...

Note: I am not advocating against using these kinds of language. Obviously, I still work in Lean and a little in Agda and some related languages/projects, so I think this direction is right. Probably biased in that I love them with or without LLMs, but I do think they're also more ideal for AI development. There are still just challenges in getting agents productive in them, and most of the challenges are not about the type systems but the actual ergonomics and dev experience.

I write Haskell every day, both for work and in my free time. Without commenting on the general quality of LLM generated code, my experience is that Haskell is at least as good as any other language for LLM code gen.

It's not more popular because Dan Luu actually measured this [1] and those languages aren't better in practice.

A priori, it does seem strange. But the relative Haskell vs Python tokens in the internet go a long way to explaining it, as another commenter has said.

[1] https://danluu.com/pl-tokens/

The popularity or the lack thereof has nothing to do with AI. AI writes good Haskell code, certainly not worse than much more popular languages like Python.

But I just don’t think terseness matters much; most of the cost is spent on reasoning tokens, not the sheer volume of code output.

LLMs predict next tokens following their training data. Following "so i wrote this little program in", "Haskell" is not a likely prediction.

Haskell just feels too much like the academic experiment it is. And you really get the feeling that this is what most of the community and leadership want it to be.

Haskell does not have a good low level library wrappers story, unlike Rust.

Nobody prepared it for adoption nearly as much as Rust evangelists did for their language. Years of hard work they invested into maintaining bindings as hobby projects paid off.

> Haskell is very terse and token efficient

I'm not certain this is the case. I find AI better at producing code in languages where there are fewer abstractions. It's great at writing Go, because everything is there on the page in text/tokens, and I find it less good at writing (good) Swift, because there are lots more abstractions for it to reason about, which are not written in text/tokens on the page.

This is part of why I think LLMs producing dense and unpleasant to read text is linked to their ability, it's no coincidence that people have this criticism of all of the independently developed frontier models.

We can train around this, the frontier models are getting better at it, but it's a good reminder that LLMs are just text calculators at some level, and do much better when the concepts are in text rather than abstractions in our minds.

Is it really better than Lean though? I started learning programming in Haskell but gradually transitioned into Lean, both because it has almost everything Haskell has (minus laziness), great meta-programming support, and most importantly allows me to drop down into proofs / formal verification if needed.

Because Lean 4 exists, which is a strictly (heh) better Haskell.

In seriousness, Lean is indeed a better Haskell (strict-by-default, performant data structures, BEAUTIFUL do-notation, full dependent types, etc), and you indeed do see a lot of slopped-out projects in it. However, certainly fewer than Rust, to be sure. I think the bitter truth of the matter is that additional static guarantees beyond what specifically Rust gives you -- type safety, interfaces, and linearity -- are simply not worth all that much in practical software applications.

It's as popular as you make it. Nothing is stopping you from using it. People generate code for what they are familiar with or have desire for. There are people who have wanted to give rust a try and AI opens that possibility up. There are certainly less people that want to try Haskell. Furthermore, Rust has more training data so LLMs generally will provide better Rust code than Haskell code. Because of LLM, I'm back into obscure languages that I didn't have the mental capacity to carry day by day. Prolog, Lisp and Forth, and like you said, they are very terse and token efficient. However, I must point out that terse was only relevant prior to the entire thinking era, a model could use 100k tokens to think only to give you 100 tokens of final output.

The ideal language is the one the agent knows how to use.

I used prolog for a project and GPT 6.1 Sol repeatedly made dumb mistakes as if it doesn’t understand the symbolic resolution capabilities.

For vibe coded Haskell id not be surprised to see it just not use strict types, hucking strings around

If you are developing on mac and deploying to linux, Haskell is pain.

I had to switch to Rust for this reason otherwise Haskell was decent for my project

The ideal language for the AI has very short feedback loops with highly localized errors and minimal up front reasoning about types that itself provides a surface for flailing and errors. I'm not familiar enough with haskell to say for sure but I don't think this describes the language very well.

The ideal language for the engineer driving the agent has maximum comprehensibility, since review and understanding are the real bottlenecks now. I'm also pretty sure this doesn't describe haskell. It incompletely describes rust I think.

It does describe ocaml. And also gleam and maybe scala. And moonbit, developed by someone who is a proven expert in exactly this domain and explicitly targeting this problem space.

There was one post about a startup moving from Haskell to a Python because compile times had become a bottleneck for their Agents.

That's when you know a company wants to irreversibly go full vibe code. Turn their entire stack into LLM generated haskell. No one will ever read it again the end.

> Rust is getting additional adoption because of its strictness

That's doubtful. It's not strict in any way that matters, especially when LLMs are writing it. You still have to rely on tests for everything. The languages that are strict are still largely ignored.

It is seeing adoption because of a well executed advertising campaign combined with "C++ without the dependency hell" being a real value proposition.

The most interesting idea in this space I have heard is to have LLMs generate formally verified assembly. And then from that assembly generate higher levels projections in languages like Haskell to help the human understanding.

[dead]