External Publication
Visit Post

Anti-LLM Sentiment Considered Harmful

Haskell Community [Unofficial] May 8, 2026
Source

BurningWitness:

Moving to Rust… for what? Is the implication that Haskell and Rust are interchangeable? I only have about two weeks of experience in the latter, but it was more than enough for me to comprehend just how much of a pain in the butt keeping track of allocations is

I’ve got a similar amount of experience in Rust, but like you, I feel like Haskell and Rust are complementary, not competitors.

I have trouble explaining to non-Haskellers how important higher kinded types are, but they’re EVERYWHERE throughout the code base. Everytime there’s a do block is higher kinded types hiding underneath. Sure Rust has Result and with C# you can do hacks with query syntax, but they’re both just poor man’s Monads with less flexibility and more complexity.

And in real life, particularly in the backend space that I’m in, there are so many things that can go wrong that you have to handle (as you’re facing untrusted user input) the ability to deal with all that in a structured type-safe manner without making the code a litany of if-blocks just massively reduces complexity and speed of development and change.

Rust isn’t near Haskell in that regard.

But if I have:

data Pair a = Pair a a -- (or just (a, a))

In Haskell, guess what, I’ve got two additional pointers to two heap objects. No strictness or unpack pragma is going to help me here as Pair is polymorphic.

This is slow. Not stupidly slow but Java slow (arguably worse as Java has had a lot more resources put into it’s optimising JIT compiler), and whilst GHC tries it’s best to optimise this away you can’t really rely on it and code refactorings/compiler upgrades will often break these optimisations.

Yes, you can monomorphise everything/use primitive types explicitly, but then you’ve lost all abstraction and you’ve basically back to immutable C.

Rust on the other hand pushes the zero-cost abstraction route quite far, by having a compile and execution model that assumes stack allocation and recompiling functions for different argument types is the default approach.

This is a great complement to one of the few weaknesses of Haskell, but Rust really doesn’t compete with Haskell’s strengths. They’re languages which excel in quite different areas. They’re great partners, not really competitors.

tchoutri:

My perspective on the matter is that reviewing LLM-generated PRs is incredibly tiring.

Reviewing shit PRs where people have taken no care to review their own slop before throwing in front of their colleagues has always been incredibly tiring, and when repeated it’s a sign someone has not the slightest basic curtesy or respect for other people’s time.

But I think this is primarily an attitude problem but it is exacerbated by AI.

Perhaps AI makes it take a bit longer now to work out that some engineers don’t know what they’re doing and just arsing their way though it with vibe coding, whereas that would be more obvious before. That doesn’t mean AI is a net negative though, it just means you need to clear these people out of your organisations and replace them with good engineers that use AI as a productivity increasing tool, not to throw slop at other colleagues.

The code I manage and develop now is better now because of AI, because there are many refactors which previously I would have thought too time consuming to undertake, are now practical to perform. If I find a better library for the task, I can replace a ten year old library, run the tests review the code and get it out in a day instead of a week (a latter of which I may not have invested in the past).

hasufell:

people not understanding that they’re probabilistic tools

  • they hallucinate all the time
  • they make subtle errors all the time
  • reviewing slop is hard

Your three following points are right, but focusing on LLMs being “probabilistic” is nonsense. Perhaps LLMs are probabilistic, but who cares? It’s trivial to create a deterministic LLM, just use a pseudo random number generator and seed it with the hash of the prompt. Bingo you’ve got a deterministic LLM.

Will it still “hallucinate”? Will it still make subtle errors? Will it still make slop? Of course.

Plenty of compilers are non-deterministic. I believe GHC still is non-deterministic but a lot of work has gone into reducing its non-determinism.

But in anycase, I’ll trust the output of a non-deterministic compiler over a deterministic LLM.

The issue with LLMs has got nothing to do with determinism. It’s that they produce output that is wrong. Making a deterministic LLM isn’t going to fix that.

(Also the term “hallucinate” is stupid. It’s not some LSD induced brilliant insight it’s going to give you. The term “lying” is far more accurate, it’s like those sort of people you rarely meet in real life that are so narcissistic they will never admit they’re not an expert in anything)

Discussion in the ATmosphere

Loading comments...