FWIW, https://duckdblabs.github.io/db-benchmark/ linked to from the readme, every result for "Haskell" shows OOM or undefined error. (Even on the large instance, even with the small input.

Cool cool cool!

That's not what I see reported, they say Haskell tends to have bad memory layout generally and takes a 5x or so hit to performance.

In many cases it's possible to write Haskell that runs as fast as a given C implementation. However the result will usually not be idiomatic Haskell.

I’m really happy to hear that. I wish Haskell were more widely adopted and more generally accepted as a solid enterprise choice without the bus factor. I can confirm that the applicants are usually great in every respect. I tried to introduce Haskell in multiple enterprises but failed at engineering managers’ reluctance to admit Haskell as an option - every time because of the bus factor argument. Scala used to be easy to advocate for as an alternative. To me, with LLMs there’s really no need to care about the choice of the runtime language unless there are SLOs to meet or library choices due to domain peculiarities.

As for token-wise inefficiency, this is based on my sporadic observations and discussions with friends and colleagues from the past three years. I can’t give you a fresh benchmark with latest models in a reproducible way. But I’m happily willing to accept your assertion at face value. This makes me curious to see for myself how the latest models perform, will perhaps set up a quick evals just out of curiosity.

From my past experience, the latest I’ve seen were Opus-4.6 and GPT-5.5 struggle a lot with standard GHC Haskell, no extensions, nothing fancy. Not that they produced impeccable Python or Rust. But it appeared to take several turns for obvious expressions, while at Java and TypeScript they were much better - fewer turns, time, and cost for the same verified results. I had assumed that the training set wasn’t large and diverse enough for Haskell and Scala, and this was the go-to explanation with everyone I talked about it. Generated F# code was good enough but not OCaml. With C++ there’s still quite some struggle, expectedly.

To me it resorted to the question, if we’re mostly generating code through LLMs now, which ones and what will it cost in total terms per task/capability completed. I’m wondering now if DeepSeek/MiMo or GPT-6 Luna can benefit from the terser, more (forgive the pun) load-bearing expressions.

Please note the "we had to pick the best of multiple candidates". Easy to hire haskellteers, but Haskell shops are not many. You would probably find more Clojure roles, but they are in decline.

With LLMs, I'd expect if something appears more frequently in the training data, then the LLM would be more effecient or smarter at dealing with it somehow.

Surely there's way more content related to programming in Python, JavaScript, Go, etc. than in Haskell.

So you'd expect some things like: an LLM is likely able to come up with an approach that's suited to Python/etc., and an LLM is likely able to work its way through Python/etc.

My experience has been: when using an LLM with a nice language (Nickel-lang, a modular configuration language with types and contracts) that it frequently guesses slightly wrong as to what works (e.g. guessing wrong about how stuff like { x = x + 1 } would work) that it spends more tokens than it otherwise might.