Remix.run Logo
rudedogg 10 hours ago

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.

bygosh an hour ago | parent | next [-]

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.

anthonypasq 8 hours ago | parent | prev | next [-]

compilation time is massively important for developing with agents

rudedogg 8 hours ago | parent [-]

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.

MeetingsBrowser 8 hours ago | parent | prev [-]

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

triyambakam 8 hours ago | parent [-]

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

gr_norm 8 hours ago | parent [-]

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.