Java 21, Spring Boot 4.x, Spring AI 2.x - probably most boring stack that is working fantastic for me to generate solid, reliable code for agents, mcp servers using Claude Code or Cursor.
Use boring languages with LLMs
101–110 of 180 posts
Re: Use boring languages with LLMs
#102This made me remember of a benchmark that I saw a few months ago about LLMs being unexpectedly _very good_ with Perl when compared to any other language. I couldn't find it right now. If someone knows what I'm talking about, please post it here :)
Re: Use boring languages with LLMs
#103Contradictory anecdote: there’s basically only one way to write Elm, as it is a very trend-resistant language with minimal updates over long timespans, but most agents in my experience will throw Haskell syntax and Prelude functions into their Elm output. Compiler or LSP will often set them right but they still try it initially
I keep asking LLMs if I can define an interface implementation as an expression or without creating a new type in C#
Every single one I ask always happily says yes, and starts claiming C# has local classes (a feature of Java)
Re: Use boring languages with LLMs
#104When you're working on something difficult that requires a model to reason intelligently, lower level and strongly typed languages often outperform on the same problems [0]. We have a few hypotheses about why, with a moderately high correlation between performance and token density of the output program -- i.e. more token dense languages are more difficult for programs to reason about.
Most models come up with the least effective solutions when writing Python.
Re: Use boring languages with LLMs
#105Earlier quoted context omitted.
The problem is that most of Rust annotations are related to memory management in special conditions aka solving problems that don't even exist in JS or Java. That's not going help the AI solve problem space issues, it just helps the AI (and us) do things in the solution space aka solve lower level things we consider important.
Memory management annotations are actually quite rare in Rust. It mostly uses plain RAII as seen in C++. You do need to annotate whenever an object may have multiple "owners" extending its lifecycle (which requires refcounting) but that's often directly visible in the problem domain.
& and &mut is all over the code in Rust. &T by far the most common arg type.
In the OP article, they mention 'don't need to worry about thread cause the concept does not exist' - well, & does not exist in Python.
Those things are related to low-level computational issues (memory management) not problems space issues (moving money, transcoding the file, checking the spreadsheet), so a lot of &/&mut etc. and all that extra thinking slows down AI for the same reason it slows down you and I.
In particular, building in rust requires us to think a bit different about how we create the program in the first place and I don't think AI is very good at architecture yet.
Probably ... eventually none of this will really matter though, it will just be like 'compiler pedantry' for the small number of people who work on those things.
Re: Use boring languages with LLMs
#106Why are we having computer programs generate source code in the first place? Shouldn't they generate something lower level, like an AST or some computational graph or something? Source code is made to be written and read by humans, and is then translated into machine code via various transformations. In theory a program should look the same to a computer no matter which language it started out as.
We have decades of compiler research, static code analysis etc, why do these extremely complicated black boxes of billions of parameters have to produce readable source code as their main output?
Re: Use boring languages with LLMs
#107Why are we having computer programs generate source code in the first place? Shouldn't they generate something lower level, like an AST or some computational graph or something? Source code is made to be written and read by humans, and is then translated into machine code via various transformations. In theory a program should look the same to a computer no matter which language it started out as. We have decades of…
> Why are we having computer programs generate source code in the first place? Shouldn't they generate something lower level, like an AST or some computational graph or something? Source code is made to be written and read by humans, and is then translated into machine code via various transformations. In theory a program should look the same to a computer no matter which language it started out as.
Presumably because LLMs are trained on corpora read, and for now still probably mostly written, by humans, rather than on corpora consisting mostly of ASTs or graphs?
Re: Use boring languages with LLMs
#108Why are we having computer programs generate source code in the first place? Shouldn't they generate something lower level, like an AST or some computational graph or something? Source code is made to be written and read by humans, and is then translated into machine code via various transformations. In theory a program should look the same to a computer no matter which language it started out as. We have decades of…
In 5–10 years there will be no more code written by humans.
Re: Use boring languages with LLMs
#109My experience is that higher-kinded languages (ie. Haskell) allow for "controlled chaos". I design a type-system, the higher kinded types, the interfaces (though it's getting rarer I need to do this) and I let Claude slop the implementation.
Additionally, fault-tolerant languages such as Erlang/Elixir allow me to not worry about the billions of edge-cases, and let Claude aggressively implement a mostly good-enough application. With LLMs, accepting a limited amount of failure may be a necessity (depending on the business/domain), and that's exactly what the BEAM enables.
Re: Use boring languages with LLMs
#110When you're working on something difficult that requires a model to reason intelligently, lower level and strongly typed languages often outperform on the same problems [0]. We have a few hypotheses about why, with a moderately high correlation between performance and token density of the output program -- i.e. more token dense languages are more difficult for programs to reason about. Most models come up with the le…
That's a very interesting page, but the language ranking is wildly different for "average percentage" (python bottom) and "success rate" (python second). Sounds like there is some subtly about this.