Haskell is I think a great language for llms - just make everything as pure as possible and you are golden.
Use boring languages with LLMs
81–90 of 180 posts
Re: Use boring languages with LLMs
#82>Languages and ecosystems with low variance in their training corpus are represented better and executed more reliably by coding agents.
Just narrow your window of thought to easier problems for the LLM, and all of a sudden the LLMs do everything you want!
Reminds me of playing around with image generation models. Someone who's been practicing can crank out prompts for really impressive images back to back. But you try to use an everyday object or concept the model isn't trained on? Everybody will race to show off how smart they are by saying "just don't hold it like that."
Re: Use boring languages with LLMs
#83My experience a year ago (back when half of HN was still in denial about what was already working, let alone what was to come) was that Python was the linqua franca of LLMs. You could achieve almost anything that fit in 700 lines or less if you told it to write it in Python.
Times change, and I work more in R&D space than on legacy codebases, but I still ask it to write something in Python then convert it to the actual language on occasion. I don't know if I'm tricking the context window, forcing alternate pathways, or both, but it works.
Re: Use boring languages with LLMs
#84I wonder what we end up with as an LLM-friendly programming language.
It's likely to be something rather formal, with entry and exit assertions. Humans hate writing those, but LLMs need them to keep them on track and give them goals.
Re: Use boring languages with LLMs
#85Instead of empty theorizing, we should have benchmarks for this. There is at least one benchmark which suggests that LLMs are better at writing Elixir than most other languages: see the AutoCodeBenchmark.
Thanks for the tip. If they are representative the results are quite surprising. Anecdotally, I always thought Go would be on one of languages LLM's were best at.
https://github.com/Tencent-Hunyuan/AutoCodeBenchmark/blob/ma...
Re: Use boring languages with LLMs
#86In my experience, LLMs benefit greatly from the existence of sum types and exhaustive pattern matching.
Re: Use boring languages with LLMs
#87> Python is the same story but sung in a different key. Asking a simple question like “which package manager are you using?” This is annoying but only needs to be solved once at the start, either by the LLM or the human guiding it. A single prompt of "Set up a uv project in this directory with Python 3.13" is enough that it's never an issue again for that repo. > Goroutines are a far more tractable primitive for codi…
RE the article you've linked: > everyone knows goto was bad. Absolutely hard disagree. You can write extremely clean and resilient C with C89, goto, and a handful of rules. Telling people `goto` is bad is how we get shitty C programs and paradigms where goto would have been better. Goto isn't bad, its misuse is bad. Beginners will write shit code regardless of whether you tell them they can or can't use goto. That's…
I have written C code for several decades. I hate a priori, divorced from context, rules such as "never use goto". "Avoid premature optimization" as a rule is much worse. I used goto a few times in that timespan, surrounded it with rebellious comments, but largely the advice has more than weakly held for me. I don't think goto somehow liberates C developers and avails superior architectures.
Re: Use boring languages with LLMs
#88Instead of empty theorizing, we should have benchmarks for this. There is at least one benchmark which suggests that LLMs are better at writing Elixir than most other languages: see the AutoCodeBenchmark.
Thanks for the tip. If they are representative the results are quite surprising. Anecdotally, I always thought Go would be on one of languages LLM's were best at. https://github.com/Tencent-Hunyuan/AutoCodeBenchmark/blob/ma...
In my experience, LLMs are pretty good at writing Go code. In fact, that’s one of my principal use cases: I have a number of bespoke Node programs from many years ago that usually run in the background on my computer.
Each process (with the Node runtime engine) consumes about 50–100 MB of RAM. One of the first things I tried was using large language models to help port them over to Go. Since the model has a point of reference (the original Node program plus its unit tests) it’s been easy to use a test-driven approach and ensure the Go version maintains parity with the originals.
Memory usage usually drops from around ~50 MB to about ~5 MB per process, which really adds up when you’ve got a dozen of these programs running at once.
Re: Use boring languages with LLMs
#89LLMs have a limited context window - similar to the limited attention span and memory of humans. LLMs also have trouble attending to many constraints at once.
Therefore the best language for agents is likely the one that, on one hand erases all irrelevant details (ie. raises the level of abstraction and does not force focusing on eg. memory management), and on the other hand encodes any domain-relevant details in the code (eg. using advanced type systems, annotations, contracts, spec-like tests eg. property-based).
Human readability is a separate concern and still relevant, but the two mentioned properties actually generally improve on that as well (at least for engineers persistent enough to scale the tower of abstraction).
Based on this, it seems Go is certainly not that "agent endgame" language. It has large amounts of boilerplate, a general lack of safety around concurrency features, a pretty middling static safety story overall with a generally underpowered type system.
I don't think the perfect language exists, yet, but just wildly imagining, it would probably be something like a cross between Scala, Elixir and Lean (or equivalents). Unfortunately none of those languages also have the large training corpus required to make them perform well in all agenting engineering situations (yet).
For any language comparison, one must separate the expressiveness of the language, which limits the long-term possibilities for agents, and the training corpus, which is what mostly gives it the current standing. I think we are still in the phase where the languages are separated by essentially random non-design factors such as the amount of training environments the frontier labs are willing to create for them.
Given that, the syntax does not matter all that much, as long as the base language itself is flexible enough - as a another wild idea, it's also possible that eg. Python could mostly swallow all these features through external tools (eg. the pre-existing type checkers or linters), and if the frontier labs bother to RL on those tools, that would also work (see also: Mojo).
Re: Use boring languages with LLMs
#90Great post showing the ironic revenge of opinionated architecture in times of cheap code. Exactly what LLMs can’t deliver, they always seem to be bias towards added complexity, not simplification.