There's no reason to add the phrase "nearly half of", and there's especially no reason to add it when it's significantly far away from half.
But on the main topic, I still feel that Go is an excellent choice for LLMs. There is pretty much just one way of doing most things, and the available training data is pretty consistent. This is very different from Python, where training data is polluted (I presume) with tons of code written by non-software engineers and demonstrating many different ways of doing the same thing.
Also a big plus for Go is the tooling. Fast compiles and good linting shortens the iteration cycle time, resulting in less need for me to tell the LLM to correct mistakes.
For some reason, most LLMs I've used default to wanting to write Python. I have to repeatedly teach them to use Go unless there is a very compelling reason to choose otherwise.
I would personally rather see and use Clojure, but I don't feel its ecosystem would provide the same benefits as Go, including obviously the easy single binary distribution.
For actual output quality, the main deciding factor is simply how much tooling it is there for the LLMs to check their own work, as LLMs seemed to avoid using a lot of libraries in general. That's why C# is underrated due to the tooling strength of the .NET ecosystem, as long as you tell LLMs to avoid using reflections unless absolutely necessary.
C++ is also surprisingly good, but you pretty much have to tell the LLMs to treat it like Go and don't use any of the dangerous features for normal code.
The need to select an appropriate 3rd party library represents an entire dimension of the search space that can be eliminated. Imagine having to make this choice multiple times per day when your competition is just mindlessly using System.* types. The fact that the .NET ecosystem is curated by one entity should not be underestimated.
Even when we do need to import 3rd party nugets, the models seem to follow this highly structured pattern. They scan the xml docs, and failing that they will build a throwaway console app to reflect over all the unique types and build a report. The fact that we can easily do this with a simple powershell command makes a big difference. How many other ecosystems can even consider doing this? Reflection is a superpower, not something to be avoided.
Reflection is just such a dangerous feature that looks like ordinary code, which is why it is something to be avoided, and having an LLM write/analyze the code for eliminates the need to use a lot of reflective code to begin with.
Another slept-on feature is the ability to quickly write your own static analyzers, which along with the myriad of existing analyzers out there, provide excellent guard-rails to prevent slop.
For existing codebases I made the experience, that LLMs are very good at replicating their style.
At work most of our C++ codebases use a fairly consistent style and subset of C++ features and to my initial surprise specifying style conventions etc explicitly turned out to be mostly superfluous.
Of course, we also have some legacy projects originally, written in ANSI C, which only received a few changes in the last 15 years to compile with a C++ compiler. Here a style guide is helpful, bit I consider it more like a temporary instruction for refactoring.
However, I struggle as well and the error messages of Oracle are some of the worst I've ever experienced.
And yet this article has pretty strong empirical data to show that your intuition here is incorrect. You should back up your statement with something more than vibes.
My experiences are of course anecdotal, but if you have some other strong empirical data to show, I'd love to see it.
Is the claim that LLMs produce Go code that is superficially nice looking but in fact fail to solve the stated problem? Because that's an anti-Go position I'd say.
I’ve had good enough experiences with Rust, but actually OCaml has been hands down the language I’ve seen best results with. The quality (and performance) of code is just phenomenal — and the main issue when working as a solo human with the language, namely smaller pool of community libraries, just isn’t an issue any more. Jane Street has really done tremendous work modernizing the language and tooling.
> This is very different from Python, where training data is polluted (I presume) with tons of code written by non-software engineers and demonstrating many different ways of doing the same thing.
Counter-example: agents with Django-related stuff. Excellent output.
LLMs seem to fall apart where human written projects of the same nature had no particular way about them. It is especially apparent when treading into waters where beginners are found. Like the earlier comment suggests, this is presumably because the LLMs struggle to find any kind of pattern to latch onto. Django offers a pattern, but one not shared by rest of the Python ecosystem. Whereas virtually all Go codebases look the same.
> "They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
This makes it a great language not just for young Googlers programmers, but also for LLM Agents!
IMO, the next big language will be similar philosophy, but without garbage collection. (is Zig the closest to filling that niche?)
Given what you said about Go, presumably that is Solod (https://solod.dev)
Python's philosophy is there is one way to do it, as opposed to Perl's TIMTOWTDI.
Your statement also assumes that 'software engineers' write the best code, and from my experience, this is definitely not true
I believe the training data should simply be limited to only code written by someone like Fabrice Ballard, or whoever you think writes the best code.
> There should be one-- and preferably only one --obvious way to do it. [1]
Note the `should` and the `obvious`. Is it not a strict rule about having a single way to do things. It is about the aspiration that, if you do something, there is single obvious way to do it, much better than the others.
(I agree though that not even this is true anymore, see how many different ways you have to interpolate strings).
As an example, there are dicts, tuples, classes, NamedTuples, dataclasses, attr.s, Pydantic, and pretty much all of those solve similar problem (hold my data) but have slightly different properties and use cases.
Also, if you trust the benchmarks, it seems that Python is, at the very least, decent enough for LLMs. There seems to be "no trouble" in practice, unless you show us better proof than "I feel like it must be bad for this and that".
> In our results, there was little sign of inter-language differences in solve rates, for any model (Figure 5b). This suggests that AI models have learned generalized programming skills, rather than pattern-matching syntax. This does not mean that implementation language is irrelevant. Conditional on solving a target, we found a small effect on token usage: successful Python solutions tended to use fewer tokens than average, while successful Ada solutions tended to use more (Appendix C). We consider these to be small differences, given that these six programming languages vary widely in how concise they are, and in how much functionality is provided by their standard library (recall that agents cannot download dependencies in MirrorCode, they must solve the task using only the standard library).
In Appendix C, Ada tended to use only about 25% more tokens than the average language. Ada is a language used mainly in safety-critical aerospace and defense systems, which has ~200x less pre-training data available than C or Python.
We're also comparing more recent language models (on just Go vs Ada, for cost reasons), on our leaderboard [2].
It's like they haven't maintained any actual software, because the criteria they choose is... Completely irrelevant?
The things that matter are tooling, orchestration and ecosystem - as well as how the LLM will actually implement the solution for a task
LLMs constantly do idiotic things. If you have good libraries to utilize, the likelihood of the solution actually working goes up because they no longer need to implement the hard part.
If you have orchestration for dependency injection, code generation, meta analysis etc
Tooling like the way otel tracing is integrated, openapi generation etc is also invaluable because every time the LLM does something the likelihood of it being hallucinated/wrong increases etc
You'd need to implement a nontrivial project in different languages, then add nontrivial features across them and only then start by rating eg correctness and incident occurrence after the final output
But token use on a one shot? Completely irrelevant as far as I see it.
I have no evidence to back this up, but I suspect that languages that are good for humans[3] will be good for LLMs. Compiled, strongly typed, statically typed, immutable, pure functions, pattern matched, memory safe, etc.
[1] https://gleam.run [2] https://lustre.hexdocs.pm [3] Yes I realize that languages features that are "good for humans" is a hotly debated topic. That's just my personal list for what I like in a language.
There are reasons to love Gleam and Lustre (I like Gleam a lot), but LLMs just aren't one of them. I made the switch to Rust around May this year. Also the community is super anti-AI, arguably with good reason (how it impacts open source), and I'd recommend keeping your AI code to yourself.
I think the language/syntax has an impact, but the tooling around it will be most important for LLMs, in the same way it is for humans.
Given it's a language that doesn't really contain any groundbreaking ideas[1] (the closest is 'use' IMO), it's possible LLMs can reuse patterns from other functional language.
[1] This isn't criticism. I love how Gleam turned out.
Too often I find them getting pulled into larger ruts in the training data and trying to insert language features that don't exist (ifs, loops, and syntactic constructs) from more popular languages like TypeScript and Rust. Do you not experience other languages getting partially substituted in when you have LLMs write Gleam?
What you're describing feels like my experience back in 2024/25. Back then I was using a llm auto complete or the chat interface, and I would get weird stuff all the time. (not just gleam but any language).
It was a shit show and just couldn't write anything that would not crash. Super confident it had done a good job. Full of random bugs. A UI needs interactivity, interruption, handling exceptions. It produced some of the worst code I've ever seen. And looking at the libraries' code: also some of the worst code I've ever seen.
I switched to rust + tauri. In about three person weeks of work I have UI with forking conversations, tool use with built in grepping, tons of quality tools. It's more productive (for me) than Claude Code (CLI or desktop).
UI is harder for sure, but it's not that bad. You need to think though where to catch which exceptions.
LLMs might opt for langchain which has had multiple breaking changes after the knowledge cutoff, making it hard for the LLM to work with it. This is probably going to lead to the LLM having to make many changes to it's code, making it messy and leading to further code being less maintainable.
I've been trying out Lean for related reasons, to good effect. It's really interesting there since it can crank out proofs that would've been completely infeasible for a dedicated team of PhDs before, whereas I haven't seen any LLM projects written in Python that I couldn't have slung out in a few months myself. I personally think it's a lot more interesting to focus on the new things you can now do with LLMs that weren't possible before, as opposed to doing the same old stuff at moderately higher velocity.
Which programming languages are most token-efficient? - https://news.ycombinator.com/item?id=46582728 - Jan 2026 (91 comments)
That leaves Go, Rust, Python with type annotations, and Typescript. And, I choose them in roughly that order unless there's a reason to choose otherwise. Rapid iterations on scripty tasks get Python. Most CLI, system services, and web apps are Go. Desktop apps and games are Rust. Typescript if I don't have a choice (i.e. it runs in a browser).
What I see from results like this is that the delta between languages is small enough now that it's hard to justify not not using something like Rust for the performance and correctness benefits if you're using LLMs and it fits the domain
Coding agents do much more than generating code though. Much of what they do relates to validating that what was generated is a valid solution. That includes everything from type checking, running tests, static code analysis, linting, running code in a headless browser, etc. The more tools agents have at their disposal, the better the feedback loop gets. But of course some of these tools are costly to run.
Statically compiled languages have a head start here as they simply exclude entire categories of bugs that a dynamically typed language might have. And with things like type inference, their token overhead can be pretty minimal. Modern languages like Kotlin or Swift are pretty compact and don't really add a lot of bloat relative to say typescript/javascript. Go is a bit more verbose but tends to work well. Rust seems pretty popular with LLM users as well. The main challenge with languages like this is the performance hit you take running their build tools. Doing that a lot slows you down and it burns a lot of tokens as well.
For instance, if an application can be broken down into components that have a verifiable contract in how they are to be used, then an LLM can load only the relevant modules into its context and fully understand how to use them and fix them if needed. It is also easier for the LLM to verify the functionality of a component rather than the entire system.
Additionally, in an application composed of functioning components, issues are more likely to occur at the boundaries between them, which the LLM can focus on rather than having to always consider the entire application that it most likely can't load fully into its context.
A well designed componentized Python application will likely be far more efficient for modification by an LLM than a large Rust monolith.
I know this because my agent already knew this the other day when I was evaluating compression, but that's because it has access to search.
That's a key part of what makes agents good coders too, mine is often looking up and downloading the source for how libraries are implemented.
It seems unnatural to air-gap them for evaluation.
I guess they didn't want them just finding an existing library to copy, but it's not very "real-world" to deny the ability to search quickly.
That said, the best language is still just the one you know. No amount of token saving is worth getting a bunch of code back you can't easily understand and review.
I have used it, and I can say it is really nicely written.
Matt Pocock has created a good tutorial on it:
that being said, those languages obviously have limits in applicability looking at the entire spectrum of software. JS, python and others still have useful domains.
i dont think newer languages as rust are better for LLMs as they might be for new programmers. for new programmers they offer extra features but for an LLM this is added potential to make mistakes. Also a lot of newer languages are less stable so you can realise their current implementations might not be fully trained on by the models or even be after their cutoff date..
But, when working on a creative graphics task, the results were best in Lua, middling in integer-only C, and underwhelming in ASM in terms of creative depth.
If this was true, the programming languages that are very much on the left side of
> https://danuker.go.ro/programming-languages.html#non-math-ma...
> https://danuker.go.ro/programming-languages.html#overall-map
should be very ideal for LLMs, in particular if they are dynamically typed.
What I can tell you is: I experimented with AI prompts for generating Wolfram (Mathematica) code using some LLMs, and I can tell you that the results were very disappointing: in my experience LLMs have difficulties with programming languages that are
- very concise, and
- for which there is less code publicly available.
Wolfram (Mathematica) is a good example of such a programming language.
- It is a rather simple language - It has a lot of very useful libraries already built in.
With just a single main.odin file you can do a heck of a lot stuff, which LLMs seem to like.
> - It is a rather simple language - It has a lot of very useful libraries already built in.
> With just a single main.odin file you can do a heck of a lot stuff, which LLMs seem to like.
Also Wolfram/Mathematica has an insane amount of useful libraries already built in (there even exists the saying "Python is 'batteries included', Wolfram is 'spaceship included'"), and also there in a single file you can do a heck of a lot stuff.
On the other hand:
- LLMs tend to hallucinate non-existing function when you ask an LLM to code something in Wolfram that is not commonly done (concerning this point, nevertheless keep in mind that Wolfram is often used for "one-of-a-kind programs", i.e. for writing very specialized programs that have possibly never been done before).
- Wolfram code tends to be quite dense.
- If there is a small mistake in Wolfram code, the code typically simply won't work.
There is a way to check whether a symbol has been defined:
ValueQ[FunctionName, Method -> "SymbolDefinitionsPresent"]
Replace FunctionName by the function name that you want to check.
One thing that often happens with board games is rule issues in translations. Specifics that are clear in one language get lost in translation. Wolff Designa is out of Latvia. So not surprised there are some hard to interpret rules.
It’s interesting that LLMs struggle with the board game rules like we do. I think game designers should get the llm to teach them from their rulebook. If an LLM can’t understand the rules good chance people will also be confused.
What is the best language to have high quality correctness oracles so that the user doesn't have to babysit the LLM and do lots of manual testing?
First of all programs written in curly-brace languages still also have indentation to indicate statement grouping / blocks / scope, even if it's not required, so for a correct program (and that's not deliberately obfuscated), and one that's in the process of being written by an LLM, any advantage there disappears. Furthermore, having both indentation and explicit block markers provides redundancy which could be a significant advantage for an LLM (it being a probabilistic text / program generator). And for an incorrect program that redundancy is a big advantage for the LLM because it should be very easy for it to notice a mismatch of indentation and braces.
The only downside would be a very slightly higher token cost for the redundancy. I realize that Python comes out on or near the top in most of the comparisons in the linked article, but I doubt that's the reason.
The closing } ) ] token has to be generated to match exactly the beginning { ( [ many lines before. You can challenge yourself writing Lisp by hand without cursor moving backwards, and try close correctly by counting ))))))) you'd have a big headache.
A long, nested sub-routine with many () {} will cost LLM's context and makes it underperform, because the attention head have to track the state. On the other hand the indentation level can be infered as a single token[1] and saves reasoning effort.
Note these discussion is about "code generation", not parsing.
1: https://platform.openai.com/tokenizer Try input many spaces.
Asking because for non programming, if you use them instead of a wiki for a topic that has had yearly changes for like 10 years they get confused and mix releases like crazy.
Well, it did show you probably shouldn't use assembly, but that's about all it showed very strongly.
And of course it also showed very strongly that you should not base any choice-of-language decisions on single studies.
Not sure how you thread the needle on the quality vs quantity dynamic.
that and the language supports (enforces) good decision making; static typing w/ inference and a functional style as a first class concept.
which then rolls into the same result : higher quality code available.
it's a lot harder to experience an agent telling you with certainty that something incomplete is totally finished if there is a comprehensive test suite, a hard failing compiler, a strict type system, etc.
LLMs like to produce a lot of JS and python that silently fails in a graceful way -- why is that? because those languages support that kind of a failure.
when using something like go/rust the LLMs are more likely to re-iterate rather than declaring a victory when they get a strict compiler barking in their face, refusing to output.
That's all it needs, responsive enough for all devices. He can keep his styleless design but margin is always needed.
> Order food
> Food comes out as raw, unprepared ingredients
> Complain to chef
> Tells me to go cook it myself
> wtf, I'm not here to do work for free
> "Is doing something for yourself really working for free?"
Except in this case it's a gas station that only exists for the benefit of its owners and there isn't any food for sale. The owners have graciously said you could still use the microwave if you'd like, though.
And every person globally should do this as well for any other website that doesn't have a good default reading experience?
Actions speak louder than words.
@import url("https://cdn.jsdelivr.net/npm/@picocss/pico@2/css/pico.classless.min.css");
Second, I am surprised that python scored slightly better than rust. My own experience is that, when programming python, Claude would spend so much more time dealing with the code not working at runtime, while for any given rust problem, rust would likely fail at compile time, iterating faster and taking less tokens. Some tasks in python it just completely failed at, writing awful garbage. I suspect that is because there is much more awful garbage written in python. (I was trying to write an AI harness. Python seemed like the obvious choice. It was decidedly not).
But in this article, python took slightly less time and tokens than rust for both experiments.
I asked Claude: could you write a decoder, from memory, in python (dont do it, just tell me if you could)
> Honestly: I could write something that's structurally right and would not decode a real .zst file.
> The control flow I'm confident about from memory — frame/block parsing, the literals section dispatch, Huffman weight reconstruction, the backward bitstream reader, the interleaved three-state FSE loop, sequence execution with the repeat-offset rules and the overlapping-copy hazard. I'd expect to get that architecture right, and it would be readable.
So perhaps asking it to do things that are in its memory is not a good benchmark. It was trained with the C "educational decoder, and every third-party port in Rust, Go, Java, JS." and offered a working link [1] to the former.
[1] https://github.com/facebook/zstd/blob/dev/doc/educational_decoder/zstd_decompress.cMost session tokens are spent elsewhere, so an LLM that handles a token-efficient language more poorly can be worse overall.
If anyone remembers TOON from a few months ago, it was an attempt to replace JSON with a more token-efficient representation. TOON was much more compact, but when researchers examined whole-session effects, it was a wash, because harnesses wasted more tokens than it saved dealing with it. (TBF, it's possible TOON use has gotten better if later models have it in their data set.)
Unless by bits you just mean text in general, or any data since it’s all bits, in which case what you’re saying is trivially already true.
It seems like you’re saying that long term LLMs will output pure machine code as the most effective way to use them.