I mean, free functions and no general nice trait/struct/enum based architecture, random `Mutex`/`RwLock` everywhere, all your big futures inside a `tokio::select!` etc.

Yes it's great when you do your first Rust project. After a year it's a nightmare if you don't keep a clear control how the code is generated and organized.

The ideal language for the engineering 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 doesn't really describe rust either.

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

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 that they agent might think it needs to prove for a relatively trivial operation can lead to an absurd amount of code. 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...

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

I'm confused how the former supports the latter here.

Surely, you mean that LLMs are not the right kind of "AI". Languages like Haskell expose how fundamentally porous LLMs are with information.

Admittedly I'm not much better, Agda has some crazy scoping rules at times and its operators are a mess, so much worse than Haskell, but at least I don't have to re-learn from scratch after every compaction.

So, I could write what I want in haskell, and it's faster for me than to have an LLM do it. The haskell would be high-level enough and precise enough to describe what I want the program to do with less iterations than I'd have with an LLM writing code, finding its own bugs, fixing them, then having me ask it what it did, tell it what to do differently, etc.

Direct control is very powerful. LLMs take that away from us, in exchange for a great speedup. But perhaps we can use LLMs to give it back to us by making our actual programming languages more powerful.

Here's one rough example that is related to this direction:

A common convention in Lean is to write essentially two versions of a function, with a theorem proving their equality or correspondence.

So you can write a more demonstrative version that is more easily understood, which you can treat sort of as a spec that all other implementations must satisfy. And then you can set the agent loose to do whatever nastiness it wants to do to improve performance.

Here's a fun write up from someone doing just this with zip file compression: https://kim-em.github.io/blog/2026-7-24-why-lean-is-faster-t...

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.

My former company was generous enough to publish most of these[0] as open source projects. But what's really telling is that oftentimes vendoring a commonly used OSS library was unavoidable.

[0] Here's a potentially incomplete list: https://chatgpt.com/s/t_6af76fd8f2a081918fa37f8c30bdb3ba

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.

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

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.

As lower-hanging fruit, to get some style steering, but not the strictness/correctness assist in implementation, there's also doing code sketches in hs - writing without testing - and then asking for whatever code as inspired by / in the spirit of / based on the reference sketch.

The benefits of strict are still the same: once the code grows bigger you have alll kinds of guarantees built into the software, that JS/Py/Bash/C needs lots of test achieve the same.

Since writing code is cheap, it like to go more on the tests and the strong typing, simply because it is so cheap. Why write Ruby/Py/JS when you can write Haskell/Kotlin/Rust? There's simply no reason not to be doing TDD these days.

"higher level projections" - wtf is this even about?

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

Data from: https://agentduel.com/leaderboard

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/