Hacker News Reader

Comment by rudedogg | Hacker News Reader

I keep seeing these language specific proclamations, and they are annoying and reek of inexperience to me.

I’ve had a great time doing LLM assisted coding in Zig, and it seems comparable to the generic Typescript/React I do at work.

I don’t doubt simplicity and good PL design pay dividends, but everyone’s favorite language can’t be the silver bullet in our new LLM world. Things just don’t add up, and I keep seeing it for Erlang, Gleam, Lisp, C, Rust, Go, TypeScript, Python, etc.

And to pick on Go a little bit, I don’t think it has any unique qualities that make it better for LLMs, where I think you could make that argument for other modern languages that offer new features leveraging their compilers and enforcing more correctness guarantees.

View on HN

compilation time is massively important for developing with agents

I agree.

It would be neat to see a matrix of compile times vs. language features, showing things like:

- Bounds checks

- UAF prevention

- exhaustive enums

- test speed

But I think even among those the subtleties would make a fair comparison impossible.

Anyway I think this is all very nuanced, and anyone proclaiming language X is the language to use in 2026 lacks the experience/knowledge to consider these trade-offs and can safely be ignored.

do people actually claim LLMs are good with Lisp? all i've seen recently are people frustrated that their model can't seem to balance parentheses.

LLMs are surprisingly good with Lisp dialects. With a caveat - when you give them actual (homoiconic) REPL. It makes little sense treating a Lisp just like any other language, which is roughly the Unix/pipe model - batch-style. Agent spawns process -> reads stdout/stderr -> spawns next process. State lives in-between the calls and in files. Each tool invocation is stateless.

Things get far more interesting when you give an LLM a true Lisp REPL. LLM stops guessing and starts empirically analyzing current state of things and produces working solution faster, costing far less tokens.

Like if you ask any experienced dev to write a Clojure program giving them nothing but a notepad.exe, they'd immediately fail without structural editing and connected REPL. Why people expect that LLM somehow, magically do it better?

> leveraging their compilers and enforcing more correctness guarantees.

The counter argument here is that these checks cause slower compile times and were designed to prevent common mistakes humans make.

If models get good, they may not need the same checks human written code needs. For example, frontier models already will virtually never produce a typo.

Humans need time to think, but a model’s bottleneck is in how quickly it can verify its work. Slower compile times hurt a models ability to iterate.

I don’t think we’re there yet (and we may not get there). But there is an argument to be made that languages with faster compile times may be better for LLMs in the long run than languages with strong checks but slow compilation.

https://avi.press/posts/2026-07-10-after-7-years-in-producti...

"After 7 years in production, Scarf has reluctantly moved away from Haskell"

And moved to Python, pretty much for the reasons you stated

This is a rather poorly-written post that more or less boils down to "GHC isn't fast enough to let us make deep-reaching changes to our codebase all the time" (fair, but this shouldn't be necessary if your abstractions are solid? seems to telegraph very substandard engineering practices, but I guess that's what you get with vibecoding) and vague complaining about how the Haskell community isn't all-in on AI.

I was curious about this so I dug further, and by the author's own admission, they've only made the switch for basic CRUD logic without performance needs, not their core services: https://news.ycombinator.com/item?id=48865986.

It's also pretty unsurprising, given what we know about LLMs' style transfer abilities, that transferring parts of an existing Haskell codebase into Python would avoid a lot of the errors and pitfalls that codebases originating in Python are known for. From my experience writing lots of Python, this does not continue to hold true as you let the agents loose on your Python codebase.

Reply on news.ycombinator.com