Labels rarely fit well. We can't even agree on the definition of "art".
I would prefer to say "fascination", because for some people, writing code is their fascination. Is it art if only they would label it so? Because I'm pretty sure that if a "code artist" showed their code to 10 other experienced developers, not only would some of the others not consider it art, but likely some of the others would consider it low quality.
Are code golfers artists? Fetishists? What if they believe theirs is the only way - the true artistry of coding? Would all of our single-responsibility, immutable core/imperative shell hybrid-functional code be discounted as garbage? (Not poking at the code golfers; I think they do it for the challenge, not because they believe that is how code should be written; but it illustrates an extreme.)
For most people, I think it's fair to say they write code because they are trying to make something happen. If their code runs without errors, in the necessary time, and without exhausting the computer's memory, then I believe most would consider that code "good": it does the job.
Are they working with others? Will others need to read it? If so, perhaps the most artistic code is not the best code to write. I know many professionals dislike working with the code artist who makes code that is unreadable to all but the most skilled developers, because it causes friction and leads to misunderstandings and bugs.
Now we have reached the point where general purpose code is so easily and correctly built by our AI tools that there is no practical point to writing it ourselves.
Are the AI-naysayers, the purists, writing their own libraries? Are they building everything from scratch? If not, they are not the true code artists. They have made practical concessions. They just haven't graduated to the realization that code is a commodity.
I suspect the people most against use of AI for building are the people who lack the creativity - the idea sources - and live just to translate requirements into code. They will gradually find fewer opportunities, and this threat is what probably makes them get emotional when looking at AI-built products.
It basically does this. If you are in level flight or a dive, you increase speed up to a certain max (level flight max is less than dive max). If you climb, you bleed off speed. To reach high balloons, you often need to build up more speed before you can climb high enough.
There's probably room for improvement, but it's already enough fun that I can play it for several minutes at a time.
Now I'm trying to decide if there's anything else of value to add - without making it too much of anything. I think I'm about finished now.
I have had such good, consistent success with Gemini 3.6 Flash (usually on medium setting) that I forget about it. It is just this reliable, effective assistant that I use for managing and organizing information, brainstorming, and of course coding.
I honestly don't know what I would want more/better than what I was already getting... so I'm curious if I will see any improvements with 3.7.
I'm not sure I trust a source that says "just 70 tokens average, nearly half of Clojure (109 tokens)".
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.
Go is absolutely one of the best programming languages for LLMs for the reason you say, and Python is just what LLMs like to use to write short throwaway scripts. Frontier LLMs are generally pretty good at most programming languages and can pick up new ones pretty quickly. Training data seems to mostly just increase the speed which they write code, for example, GPTs tend to write Rust and Python faster than other programming languages.
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.
I think a lot of people are sleeping on the advantages of "batteries included" ecosystems.
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 good for prototyping and get something setup quickly, but if you build your architecture around it, not only do you lose access to NativeAOT, the code becomes very hard to debug, and if you code with LLM a lot, you either have to spend time trying to debug reflections or just rewrite it with source generation to begin with, which is at least honest about the metaprogramming there.
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.
> 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.
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.
If you want the opposite experience, try LLMs with an older Oracle Database. Even with the official Oracle SqlDeveloper MCP Server they struggle a lot.
However, I struggle as well and the error messages of Oracle are some of the worst I've ever experienced.
> Go is absolutely one of the best programming languages for LLMs for the reason you say, and Python is just what LLMs like to use to write short throwaway scripts.
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.
If you actually read the data, especially the distribution graph in the last image, the conclusion that it draws is "the run-to-run distribution variance is so big that there doesn't seem to be a correlation that can be drawn from this experiment", pretty much every language has similar-ish distribution ranging from ~20 to 34, and Clojure is only the worst because GPT has a tendency to write code that contains a particular byte manipulation mistake that it repeatedly makes, not that GPT is bad at Clojure or anything.
My experiences are of course anecdotal, but if you have some other strong empirical data to show, I'd love to see it.
Yea exactly. The article says there's too much noise to make any conclusion. You made a conclusion that there was a strong signal. Those things are opposites.
What is output quality without correctness? That seems like a distinction without a difference.
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.
Correctness is a suitable property to act as a multiplier in your formula, where incorrect is 0 and correct is 1, but you also need other facets to find a quality gradient.
In this context it's not binary. Context is everything. If it was binary there would only be 0 and 1 on one of the axis in the graph. That's not the case.
Correctness is binary even in context. The axis of which you speak shows distance; essentially how close the programs were to being correct. Every single sample was incorrect.
Think of it as being like a road trip. Arrival is binary. You have either arrived or have not arrived, but distance can tell you how close you are to arrival. Being almost there does not imply that you have arrived, however. Same applies here. Some samples were closer to being correct than others, but none were correct. They were all incorrect.
But as you alluded to earlier, I don't suppose anyone wants code that fails to solve the stated problem. Given that we have empirical evidence that LLMs cannot produce correct code within a given set of problems (and I suspect that extends to most problems), correctness is a weak signal.
What is a useful is to know is how much additional effort is required to make the program correct. That is what quality has traditionally meant as it pertains to code. High quality codebases are considered high quality because the effort to reach and maintain correctness is considered to be low. We do not have enough context to know for certain if that is what was meant in the earlier comment, but it seems likely. What we do know is that the comment is about quality while the article is about correctness.
You seem to be mixing up the different things we are talking about.
Yes, quality is what the earlier commenter is talking about. Yes, idiomatic code is often considered to be what makes code high quality because idiomatic code is believed to make it easier to reach correctness (easier to read, easier to reason about, easier to test, etc.) than if you have to work with "spaghetti", which is considered low quality because it makes it much harder to ensure the code is correct. Quality exists on a gradient. There exists a full spectrum between a complete spaghetti monster mess and perfect architected idiomatic code. This we both read the same way it seems.
Whereas the article is about correctness. The program is either correct or not. Distance was used in the article to share how far away a given program was from being correct. But distance and quality not the same. This is a completely different way to look at software as compared to the topic of quality, as we already established at the beginning of our discussion.
I think that idiomatic Go code is not in fact easier to read or reason about on the business domain level, because it's too low level and fiddly. That's why we don't write in assembly anymore. Assembly is much more "easy to reason about" per line of code than Go, but it's also terrible on the business domain level for the exact same measurement.
So you don't believe in "spaghetti" code? No matter how a codebase is written you will consider them all to be equally readable, equally able to reasoned about, equally able to tested, etc.? You see no difference between "organized" code and one giant 200,000 line chaotic function?
We mostly avoid writing assembly because it isn't portable. So-called "portable assembler" is still very popular. One of the most used languages out there. That has little to do with the quality of codebase, though. Focus, my man.
> 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.
I think you will find that is a supporting example. Django pushes for a particular style and structure, which is a similar property found in the Go community.
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?)
- Strict subset of go might be confusing to an agent actually (trying to use unavailable go features)
- So -> c11 source to source compile loop might be confusing to agent: if So compiles to c11 does it guarantee c11 program compiles. If runtime exception (segfault etc), is it going to be easy for agent to map that back to original So code?
Professionally, Scala was always my favorite language to work in and I was lucky to get to use it most of my career. It is, however, probably the worst language I’ve experienced using with LLMs. Next worst is any dynamic language: it’s just so hard to not introduce strange bugs after iterating on a large-ish project across multiple agent sessions.
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.
I've experience severe problems with Scala in teams with different skill levels or programming styles. Sometimes Scala code was very cryptic. As much as I like the elegance of the language as such, I've given up on it completely because it is not a good fit for industrial software development in my opinion.
having claude to work with has actually been pushing me from ocaml to rust for some of my personal projects. the LLM makes up for the fact that rust is less ergonomic, and being able to pull parts of my project out into libraries that can be called from any language is a rust superpower that is hard to turn down.
I’ve been landing on go for a similar reason, which was the realization that LLMs are in many ways just massive cargo culting machines. People will call it “quality training data”, but really LLMs will just reflect the norms and behaviors of whatever ecosystem they’re using.
I like to think go’s lack of magic and standard library will lead to lower maintenance burden over time, but that’s mostly just vibes so far.
I would argue that the fact that there is a lot of bad python code out there is actually a good thing for training data, gives the chance of learning what works and what doesn't.Also there are bad programmers that have found original solutions to very niche problems, would be nice to know about those even if it means rewriting the whole thing.
> 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.
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.
But that's the trouble, Python has the slogan about only one way, but it's really not true in practice. Or maybe there's the one way that "should" be done, and then the half dozen other ways you'll encounter in the wild, as gp alluded.
Python is the language where in practice this is most untrue - maybe outside C++.
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.
the slogan came out when the alternative was Perl, and in Perl you could do the same thing in a million ways, and each of them was equally "idiomatic".
> 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).
Aren't LLMs a way to somehow extract the one way it should be done (or to be more precise, the more common way), over the half other ways? That correct way might be more difficult to extract from another languages that encourage multiple valid ways.
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".
I am working on two projects these days, one in Go and one in Clojure and anecdotally, I prefer clojure. (Easier to review, better iteration cycles through repl, cleaner and more concise code, better domain modelling)
reply