What's the best programming language for coding agents? | Hacker News Reader

What's the best programming language for coding agents?

danluu.com

262 pointschaychoong188 comments

Related: Which programming languages are most token-efficient? - https://news.ycombinator.com/item?id=46582728 - Jan 2026 (91 comments)

Open articleView on HN

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.

And those batteries will soon include the very benchmark in this article. There'll be no need to build a zstd decoder, .NET will ship one in dotnet 11: https://learn.microsoft.com/en-us/dotnet/api/system.io.compr...

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.

I find golang very verbose and unreadable. With 1000s of lines LLMs generate, it’s hard to make sense of is it good code or bad code.

Add in golang doesn’t have proper types for Option<T> to have a nilable type. Its pointers and null pointer bugs are plenty, no proper stack traces.

I find myself to be less productive.

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

The error messages are just advertising for Oracle consulting!

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

Best to read the comments before replying. The article is about correctness, while the parent is talking about output quality.

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 binary, while quality is not.

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.

I think "quality" here refers to "idiomatic go code", not the distance from the end broken state to a finished product. At least that's how I read it.

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.

I like Go with agents too but:

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

Agree that go is the best due to its main design goal: A language that's simple for any programmer fitting that definition https://news.ycombinator.com/item?id=30688969.

> "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?)

> is Zig the closest to filling that niche?

Given what you said about Go, presumably that is Solod (https://solod.dev)

Interesting project.

2 gut feeling concerns:

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

You can rather easily ship Clojure apps as single binaries, eg with this: https://github.com/avelino/jbundle

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.

As someone who has mostly written Rust and Python over the last 10 years... yeah. Go is actually a really solid choice for Agents IME

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

[1] https://en.wikipedia.org/wiki/Zen_of_Python

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’ve gone down the same logical pattern of using Go for llms even though I personally prefer Clojure.

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)

Ive been amazed at how well LLMs are at writing Gleam[1] and Lustre[2]. Compared to a mainstream language, there is basically zero gleam code in the training data.

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.

I used to hold this opinion but since changing to Rust on the server and Typescript on the client, I can confidently tell you agents are so much better at Rust, especially at producing idiomatic code, than they are at Gleam.

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’ve been developing a language for a few years, and even with incomplete semantics and a simple one page example LLMs don’t have much trouble writing it.

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.

I'd agree. I've spent the last month running an experiment, having an LLM being up a self-hosted compiler. It has no problem writing complex code in a never before seen language with severe constraints[immutable, no naked recursion, recursion schemes].

The biggest challenges are maintaining non-functional requirements, specifically CPU and memory effenciency.

Gleam has been stable for over two years, so maybe it's been long enough that LLMs have internalised the documentation.

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.

That's not a take I was expecting to find here. I've found most LLMs absolutely dreadful when it comes to Gleam, to the point that I most often disable even inline autocomplete when working in Gleam codebases.

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?

I suspect it depends a lot on the llm/harness being used. But when I use Opus/cc or sol/codex, at the end of the turn everything compiles, passes tests, and passes lint. I never even look at code that can't compile. Maybe the LLM is generating weird stuff in-between, but I don't see it.

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

You’re talking about autocomplete! That’s always a poor model doing it because it has to be fast enough. I never use that anymore in any language, it’s only occasionally helpful. I suspect everyone is talking about agent harnesses here , not autocomplete. With a harness, the agent not only can be more powerful (and slow) it can go into “thinking” mode and once it comes back with some code , it’s almost always quite good. I think this is true in Gleam and in many other languages, no matter how minor, as long as it has good docs and good error messages so the AI will fix dumb mistakes before you get to see it.

I think that just shows LLMs are great at almost any language. As the post says, it can get very poor, as with J and Factor, but anything remotely easy to read for humans seems to be perfectly fine for LLMs. I can say I am still to try a language they struggle with myself. Tried Dart, Groovy, Common Lisp, Elisp… and more. It is an expert in all of them and I can’t really tell they advantage one over another. Our mixed Kotlin Java huge code base is a walk in the park for Opus5 and Fable5.

For an even more niche language, Roc basically became usable in the new syntax about two months ago (still has compiler crashes, there's a good reason it hasn't had a real release) but Opus writes it just fine after a couple corrections to handle the language's quirks.

We studied this question pretty systematically in the MirrorCode paper [1], comparing Python, C, Rust, Go, OCaml, and Ada across 19 very long-horizon tasks, for Claude Opus 4.7 and GPT-5.5.

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

[1] https://arxiv.org/pdf/2606.30182

[2] https://epoch.ai/MirrorCode#leaderboard

Reading your quote really gets me wondering who the people making those kinds of analysis are...

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 think the main advantage of Static-compiled-strongly-typed languages will be that it will allow the [automated] generation of comprehensive static analysis test suites to provide specific and explicit assurances about the code.

That is, for larger, more complicated software. There could be a set of static analysis tools that guarantee the correctness of the code. This would be very cheap to run and maintain.

Contrary to what most comments seem to indicate, my takeaway from this is that it doesn't really matter all that much for the agents what language you pick. If humans are still to be involved in the process at some point, then its imperative that the language can be read by them, so the preference or skills of the developer(s) are of primary concern, not the agent.

Similarly contrary: I don't know why people aren't talking more about Python. Am I interpretting the final vs. graph incorrectly?

I've got some education in materials engineering; it'd be trivial to drop a curve (line) for optimizing the language selection, and Python obviously comes out on top.

The author doesn't even mention it. That discredits the whole article as far as I'm concerned.

You are the one cherry picking perhaps the first two charts. Look at the various metrics at the end in the Zstd vs Pandoc charts. There is just no clear advantage for Python across those metrics which are the one you really want to know about! If anything F# seems like a better top of the line language?!

I'm exclusively using the third chart. The selection process would naively be y=mx+b with some reasonable variables. It would be a downward diagonal (you would move it right until only a few remained), and you would pick the one farthest from the line, which is obviously Python.

Edit: I misread the chart! It would indeed be F#

It's not clear to me how useful of a signal replicating existing pieces of well-known software is for this kind of evaluation, given what we know about how effectively LLMs can retrieve data from their training corpus and style-transfer it across different settings (programming languages here). That would explain their convergence in ability across different languages on the tasks in this post. I'd be far more interested in people's real-world experiences.

I tried writing an AI harness in Python. Seemed the obvious way to go. Tons of libraries. Libraries for talking to model APIs. Libraries for context and conversation management. Libraries for talking to MCPs. It is the language for LLMs!

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

Yeah, I've had similar experiences, also starting out with dynamic languages and migrating to Rust. If the LLM will write a lot of the code for me, why not choose something (1) super fast, and (2) which has types I can use to understand and specify the code I want without having to read all the output?

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.

I was recently working on an AI harness too, but I wasn't using AI to code it. It's really easy and requires little code. I wasn't even using langchain - that would require even less code.

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.

Which programming languages are most token-efficient? - https://news.ycombinator.com/item?id=46582728 - Jan 2026 (91 comments)

This area moves so fast is something from over 6 months ago still relevant?

Fable and Opus 5 have been released since then along with the corresponding OpenAI models.

One thing worth noting is that syntactic density doesn't necessarily mean cheaper because because symbols don't chunk/tokenize as well as plain English

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

Cool line of questioning, but one piece of information is pivotal and critically not-yet-included: equivalent accomplishments in each language. For example, if I want to write standard things: web server, memoized fibonnaci, recipe search engine, what's the length-and-density of these outputs for each language? I think that would add in some ~normalization.

Strongly agree- this is how I “evaluated” languages pre-agents. though I suspect this would bias results in favor of whatever has best signal to noise for boilerplate from stackoverflow/reddit , rather than what LLM’s “””reason””” best with. (Presuming those aren’t quite one-and-the-same)

This is a great discussion: I wonder though if we are asking the right question. Yes, absolutely language choice can play a large role in the efficiency of coding agents. The point about Rust is right: static typing provides a fast verification loop at compile time. I would argue though that the way the codebase is composed could actually generalize the concept of "easy verifiability" past the actual coding language.

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 wonder though if we are asking the right question

I also wonder. Is there no further design thought, research or discussion on how to better modularize a program to address complexity - in an LLM world?

Instead, we still can’t move beyond arguing about languages …

> Most of the claims that get thrown around about how a particular language is good for LLM use seem to be wrong (e.g., the claim that Ruby, Clojure, and J, are particularly well suited to LLMs, which were mentioned in the evals linked above, as well as the somewhat common claim that Elixir is particularly suited to LLMs), but it's not clear what's right.

I feel this is a missed opportunity to explore the architecture of Elixir and why it's suited for agentic coding. With elixir, as long as the agent does all the work in a separate worktree and then applies the changes at once in the main repo, if you have a long living runtime the BeamVM is able to swap modules with their updated versions. AFAIK, In elixir every module is an autonomous actor that communicates with message passing and is isolated in their own VM. Agents can implement functional code batches and see the changes take effect in real time, no matter if it's a web server, a data transformation pipeline or something else.

I’m surprised the original source wasn’t linked to this blog.

https://dashbit.co/blog/why-elixir-best-language-for-ai

https://autocodebench.github.io/

You are not 100% correct. Modules in Elixir are like namespaces, they contain functions. They're "static" and don't communicate with anything. Processes communicate with each other via messages.

> Dynamically typed languages generally have a lower LLM token cost than traditional statically typed languages because omitting explicit type declarations makes the code more compact.

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.

I’ve actually found Sol delivers great results with Odin, despite there not being much Odin code available. I think it is able to work well with it because:

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

> I think it is able to work well with it because:

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

Is there a way in Wolfram to check whether all function names exist ? And than give it as feedback to the llm?

> Is there a way in Wolfram to check whether all function names exist ?

There is a way to check whether a symbol has been defined:

  ValueQ[FunctionName, Method -> "SymbolDefinitionsPresent"]

See https://reference.wolfram.com/language/ref/ValueQ.html

Replace FunctionName by the function name that you want to check.

It’s interesting I’ve been surprised by how well Claude sonnet can write code in a language I’m developing that probably has no code in the training set. It seems like anything with syntax like python/ruby/elixir is pretty LLM friendly, and layering on a HM type system seems to help catch most errors.

> omitting explicit type declarations makes the code more compact.

I guess this ignores languages with type inference? Hindley-Milner and others

Training data is a factor too

I love Dan's writing. I really do. But I don't understand why he doesn't have some basic styling on his blog so that it's easier to read.

I love this take because I had exactly the opposite idea. I thought the combo of remarkably simple text (not even wrapped) with incredible, full width visualizations was chef's kiss. I really like the balance there personally, but I hear you. Does your browser have Reader Mode or something like that? I don't use those tools personally, but I believe they will recast the text parts into something that renders optimally for reading (ideal font size, number of characters per line, etc....).

Enabling 'reader mode' in supporting browsers usually takes care of this.

But it eliminates JS, in this case including graphs. I prefer Ctrl+Shift+M (responsive mode) and resizing the viewport with the mouse.

It may be an artistic/engineering choice to demonstrate what minimizing bloat to an extreme degree looks like.

https://danluu.com/web-bloat/

body { margin: 5%; }

That's all it needs, responsive enough for all devices. He can keep his styleless design but margin is always needed.

Users being able to supply their own stylesheet is a core tenant of CSS. Go nuts and make it look however your heart desires!

Supply my own stylesheet? No thank you, I'm not here to do work for free.

Is doing something for yourself really working for free? That's an interesting take. But I can understand why you don't want this for yourself, so enjoy the page in all its splendour as it is already!

So every person who reads Dan's blog and finds the layout too dense, they should write and maintain a stylesheet for his site?

And every person globally should do this as well for any other website that doesn't have a good default reading experience?

CSS is explicitly designed for you to apply your own user stylesheet. That is exactly what it envisions you doing. If you don't like web technologies you might want to question what you are doing on the web. However, the web also encourages sharing, so no, theoretically once one user has created a user stylesheet they would share it with others so there would be no need for everyone to create their own, unless they had alternative tastes.

Actions speak louder than words.

If most readers of danluu don’t find that, then yes!

I mean, if it really bothers you you could fairly trivially apply picocss or whatever to it using a user stylesheet. That is so little effort that calling it working for free would be disingenuous to say the least.

For people in the future who want to apply the centered viewport classless version of Pico CSS, just apply the following in Firefox's Style Editor (F12 to open DevTools, then click on Style Editor; click on the + sign to add a new style):

  @import url("https://cdn.jsdelivr.net/npm/@picocss/pico@2/css/pico.classless.min.css");

I honestly did not know that until I took about 5-10 minutes looking up how to apply arbitrary styles in Firefox.

Browser vendors have really dropped the ball in supporting CSS, which is no doubt how we get comments like the above. Firefox is likely the least-worst offender, but as you point out still needlessly complicated for what CSS considers to be a foundational feature.

Multiple people, me being the third or fourth, are not feeling the default layout and you all read that as a signal it's working as intended?

No, just that it’s easy to change for those that don’t like it. Clearly some people do like it (including Dan, presumably).

> Go to restaurant

> 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?"

A closer analogy is going to a gas station where a microwave is offered to heat up any food you purchased. If you don't want to heat up the food, cool. If you expect the food to come hot you're in the wrong place.

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.

HN’s favorite CS professor homepage webpage-style author is on top of the AIs but sticking with keeping out newfangled CSS. Nothing could tell us more about clanker inevitability.

reader mode helps.

Zstd gets rather easier from dotnet 11, it becomes a near one-limer since it's getting added into System.IO.comoression.

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 discovered last week that Fable 5 can write perfect xTensa LX7 assembler code without tools or references. Mind blown.

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.

Python has a less known advantage because it had no curly braces, so LLMs can focus its attention to logic instead of syntax.

https://blog.est.im/2026/stdin-11

It's unclear that this is an advantage, certainly not in terms of "logic vs syntax".

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 thing with LLM is they don't automatically pair parenesis/curly braces like we do with editors/IDEs.

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.

I really don't understand this argument. The "opening tab" in Python has to be matched with an "absence of tab". I don't see any non-cosmetic difference between Python and curly brace languages.

Was going to say the same thing, both of them have to deal with the same amount of context. And curly-braced code will have indents anyway.

Interesting to see Factor and J so far to the bottom and right in the zstd test, but much closer to the rest in the Pandoc test (with Asm taking their place). This suggests that both the task and language (not just the language) influence the efficiency.

I try to use LLMs for Kotlin, Python, Emacs Lisp, and Smalltalk (among many others, but these are what I have ongoing projects in). You'd think that Kotlin and Python would be much easier to generate than the other two, right? But that's not what I observed: Elisp is very close to Python in terms of how fast and how many tokens it takes to generate the code! The generated Elisp code is often better on the first try than generated Kotlin code for a comparable task.

Smalltalk is... complex. It's meant to be developed interactively in a running image, but running Codex on API pricing is too expensive, and Codex CLI cannot interact with the image without a lot of plumbing. I ended up building multiple tools that live in the image and a protocol for calling them, and a set of skills for using them - including code search, docs search, test runner, and script/string evaluator. I also defined a way of annotating types for method arguments and return values (without having a type checker), which helped a lot. Still, it's an uphill battle; I wouldn't go there on API pricing!

My takeaway is that it's not obvious which language fits the LLMs and a given task best.

What is the best language for the user of the LLM?

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?

English, probably.

JS is the best tradeoff between succinct and easy to understand. Python is next but has some rough edges that they avoided in JS.

You are going to have to give more support for those assertions. I write Python every day, and never would I call it a good candidate for the clankers. Pretty much any dynamic language would be ruled out, as there is too much implicit logic which makes it harder to understand what is happening.

Python with a strict linter and type checker (eg ruff with the right lints on and ty with its stricter settings, or strict pyright if performance isn't too bad) works very well. Most of Python strengths (concise, large ecosystem, well represented in the LLM training data) while having good static analysis.

You don't need that, gets in the way more than it helps. Even Typescript isn't really needed, but at least it's decent devex unlike the Python typing stuff. What really helps is testing.

I trust the type system more than vibe tests.

I try to capture as much as possible in types/schemas/constraints (then lint rules) and then only as a last resort write tests. And as few and complementary as possible. And I want a functional core with unit tests and imperative shell and not a bunch of complex mocks. ¯\_(ツ)_/¯

Some kind of testing is needed if you care at all about it being reliable, whether or not you have type checks. It can just be a few simple tests like a smoke. You don't need tests that directly check for correct types. If you're using a wrong type somewhere, it'll become obvious. Without type checks, I've never had a bug in prod caused by wrong types, it's always something else.

What's better for this, Go? That's the least verbose static one, and it's still a lot more verbose without helping you understand any better what it's doing. It's just faster. That's the real benefit of static types.

JS gives you wrong answers silently when thigns go sideways since for the original browser use case, they didn't want scripts to ever stop execution. It's the opposite of Python in this respect.

Yes Py is stricter, but you pay for that with more verbosity, which in turn makes it more error-prone. And the kind of strictness it adds barely helps.

I feel Python is more concise. Looking at a couple of Rosetta Code examples, they are shorter for Python as well.

Also the post referenced by the article lists Python taking noticeably less tokens than Javascript.

It can be if the task lends itself well to list comprehension. Data analysis / script types of things will likely be in Py rather than JS either way. But the stuff like backend code that overlaps, JS is less verbose thanks to how it deals with lambdas and objects.

Cool seeing Guards of Atlantis 2 here.

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's optimal for LLMs and for people is probably not going to be the same. People are a bit lazy.

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.

A while ago I benchmarked different tokenizers with a few common C++ coding styles. Depending on the combination I was able to reduce the token usage by as much as 5% just by auto formatting the codebase with clang-format. Of course, this doesn't necessarily mean that a coding agent would perform better, but it was a fun experiment.

I don't care so much about token efficiency and cost, within reason. I care about whether the quality of the code is maintainable over time and through many iterations. My gut feeling is that very strict languages with good types, a standardized style, and very strong static analysis tools, is what helps make that happen. Of course it also has to be well-represented in the training data.

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

IMO, rust.

Not because it is concise but because you won't need to spend tokens debugging segfaults and a whole spectrum of bugs that the compiler catches. LLMs usually write tests in the same source files so most features are implemented and working in one shot.

I tend to agree in the spirit of this. But more because I believe that Complied and statically typed rigid programming languages tend to be more "software Engineery" than dynamic. That is, as they are more "rigid" and explicit (less ambiguities) at writing time, it will allow to apply (automatically via LLMs) engineering principles, and maintain them.

The main problem with those languages is that they were difficult to write and read for people (their learning curve was steeper); but once that coding doesn't matter with LLMs, they will allow for better control of "automated verification" of the Engineering decisions that system builders do.

I compare it to say the blueprints of houses that Civic Engineers and Architects do, with plumbing lines, electiricy lines, calculations for material tensions, supports, etc. We will enter an era of real "Engineering" in Software which Compliled/Statically-Typed languages will better allow.

C and C++ do well because there is most literature and code out there to help them reason about it. C is helpful because it has little hidden runtime for them to trip over.

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

Great post. If it wasn't clear by now, considering a language's token efficiency is almost certainly incorrect, since it's only a local optima for input/output of the code.

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

Architect your system to use the best tool for each problem. Doing a minimal data pipeline? Use Python. Building a backend? Use Go. Building a frontend? Use React / Typescript.

Building a stack that does all of these? Still use Python, Go, React/Typescript. Because by architecting it this way you make the AI less likely to accidentally refactor logic between layers. In other words, architecting with multiple languages helps create persistent boundaries that isolate different kinds of logic into their appropriate modules.

I’ve found that nodejs/cloudflare workers are pretty awesome. Typescript everything is a pretty phenomenal stack.

I'd like to see the results for Ada on these same measures. On the theory that the Ada type system covers more classes of errors than other languages, and so AI can self correct better.

Unfortunately for static type weenies like me (and you, presumably), types don't seem to matter at all, or Python and Javascript wouldn't be on top. There's no reason to believe that Ada's type system is so unique that it alone can help AI self-correct, and Rust, Haskell, ML, Typescript, etc. can't.

Well the reason I'm interested in Ada is because I saw a study that showed AI did worse at functional programming. So that might explain the problems with Haskell et al. But Ada has a strong type system while still having procedural code. So it would be an interesting comparison with Haskell etc. if the problem was that Haskell is functional or if the problem was that these are not so popular.

The study didn't really show that. What it did show, is that in this particular study there was no strong effect either way and there is really no way to generalize from the results. See in particular the details on what made the agent stumble, it was things like "cargo repeatedly gets invoked with the wrong arguments" - nothing to do with functional or static, just ecosystem idiosyncrasies and trivial differences.

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.

You're in luck! https://news.ycombinator.com/item?id=49254706

Thanks

I wonder if there's correlations between tasks and languages, e.g. maybe R is better for bioinformatics tasks, python for webdev, C for CLIs, etc. I'd expect to see it because some languages are used more often in some tasks than others, but on the other hand LLMs can learn across languages and it's not clear if task-language use patterns are just historical or if the language is genuinely better at the task.

For me c wins here. It is compact, there are all language parts one needs and available and it well fitted to transport knowledge without much syntax hussle

This analysis might benefit from a multivariate regression. You mention a few different explanations for why performance differs and if you could get solid numbers for those you could try teasing that apart.

Also a small note: the axis on one of your plots alternates between 4% and 5% increments whilst holding the ticks constant. Maybe because of rounding?

I'm surprised there is no breakdown of "with skills" (framework) and without. In my experience, apart from human readability, the ability of a model to follow strict skill rules is the important. For example I see a lot less waste of tokens and reasoning retry loops of obvious errors when using Python with uv+ruff than without.

I added pyright hooks to any edit commands in the code base and it works very well to keep it in the rails. Only trick is to set the unused import as a warning due to the way it edits files. Generally, type checks really help with getting the ai outside of its window vision when doing partial edits in the files.

Any good LLM service (not just coding-focused ones) will write and run ad hoc code without being asked if your prompt involves lots of data. Gemini and Claude tend to pick Python with maybe some SQLite. Some of that must be due to portability alone, but it also means they'll make sure the model and tooling are good at those.

I few months ago I tried to make a project using Fennel (a lisp flavor of lua). I always wanted to use lisp, and hey, since it was the OG AI language I though why not.

Claude could work on it okay apparently but some local llm's struggled with it and got stuck in reasoning loops trying to close the parenthesis.

First, How fast is the Zstd decoder in python at runtime? If rust and python are essentially the same cost, then chose rust.

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

How good or bad are LLMs on languages that have evolved over the years and aren't popular enough to get hand tuned?

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.

Is there a relationship between how good a programming language is for coding agents and how popular it is among humans? If so, wouldn't Python be the best language for agents, since it's is the most popular (and hence has the most context available for models)?

Pick something slightly esoteric (eg Haskell) and the quality of public code is very high, because you only have enthusiasts writing it. Choose something taught in schools (Python) and you are going to find 10,000 traveling salesmen homework problems and Django todo applications.

Not sure how you thread the needle on the quality vs quantity dynamic.

>Pick something slightly esoteric (eg Haskell) and the quality of public code is very high, because you only have enthusiasts writing it.

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.

Your point is a good one: Exotic, difficult languages attract enthusiasts with deeper skills than a median developer.

Haskell also has a confounding issue: Because of its focus on research and experimentation, standard best practices don't exist like they do in languages optimized for real-world use. Because there are few community guidelines, engineering practices vary widely, and unfortunately at the same time, Haskell's public codebase resources are small.

To see this playing out, check out Haskell discussions about choosing a SQL library, effect system, monad transformer stack, or web framework. The answers are all over the map because that diversity is baked into Haskell's culture and practice.

Was going to ask what is the Numpy equivalent in Haskell. Cause Python has a thousand decent examples of how to do everything you might want to do in Numpy.

Quantity, it seems is a quality in itself.

As much as I love Python, JavaScript (including TypeScript) is probably more popular.

I was going off this for popularity: https://stackoverflow.blog/2023/01/26/comparing-tag-trends-w...

That and JS code is more readily available in the source of tons of webpages, not hidden away in some backend

Wouldn't most frontend JS in Web page sources be minified?

The logic is still there, it's not meant as obfuscation. Also plenty of sites don't minify cause that involves a whole toolchain.

There is definitely a relationship. But I personally believe that once the training corpus reaches a certain scale, the returns exhibit diminishing marginal effects, to the point that multiplying the data volume cannot surpass something essential inherent in language design. (Asked an LLM to help me with the translation, so forgive my expression)

there is a relationship there, but there is also a relationship to the safety of the language and the guard rails in place.

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.

In my experience, Dart/Flutter has been so much better than React. Go has been really good for the backend. Basically if the framework/language gives you structure and one way to do things, agents tend to create less mess with less guardrails from you.

I believe soon we will have a language made exclusively for coding agents that will be highly token efficient and difficult for humans to read, as human-in-the-loop will be ditched entirely.

The article seems to me to be quite poorly written. In addition, voluntarily or not, this begins to resemble research work, without the formalism that would be necessary. So, I have the impression that we can objectively get nothing out of it.

The benchmarking in the article gives a clear answer to the title question: Python and Javascript. However, the article doesn't just bury the lede, it misses it entirely, getting distracted by outlier results from clojure and j.

Clojure's performance improves dramatically with an MCP REPL server. Part of that improvement is that the LLM gets parens balancing for free.

So Javascript beats typescript in correctness???

Correctness here is not about just writing bug free code, but the code that actually gets stuff done with correct results. JS might be better for this, at least up to some scale.

Had the same experience as a human. The time and focus spent on the types wasn't worth the validation it added. I suspect the LLM's issue with it is just the additional token usage, which is sorta analogous.

I think llms provide a really excellent way to do studies on software engineering techniques that previously were impossible.

i dont see enough love for Ruby. I've been using it since last year and it feels like php's more robust brother

+1 for this! Given Ruby's entire thing is code "written like plain English," I would have expected LLM's to excel with it. I've certainly had awesome results.

I can highly recommend TypeScript/JavaScript with AI SDK:

- https://ai-sdk.dev/

I have used it, and I can say it is really nicely written.

Matt Pocock has created a good tutorial on it:

- https://www.youtube.com/watch?v=mojZpktAiYQ

I've long suspected that LLMs will just output pure bits eventually

Why would this be the case when the text that produces binaries (code) is usually both more token efficient and vastly more effectively organized for modification/extension?

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.

token efficiency could become irrelevant in the long term

What about the other thing that’s the actually important part of my reply, modifiability/extensibility? You just chose the weaker of the two factors I provided. And didn’t even provide a convincing argument related to it.

You also didn’t clarify your position at all.

Explain why there is any benefit to outputting raw machine instructions compared to writing shorter, more interpretable, modifiable, extensible code and then using a compiler to turn it into machine code.

Why are agents not going to use compilers in the future?

I'm not convinced text is more modifiable and extensible than straight bits for a "superintelligence"

The benefit would be that the AI would have true hardware access. It would be unconstrained by gatekeeper protocols.

Would be very powerful, and thereby, potentially dangerous.

Or just replace all of the apps? Why would a user use apps if everything (eventually) can be achieved with an AI?

i think the main blocker to this are the owners of the App Stores themselves. Apple won't let this happen if it can help it.

well they can natively converse in base64

are you implying that text is impure bits?

when the model predicts the next token, it doesn't predict the next bit.

I'm saying, eventually, it will... perhaps :)

BASIC.

"Languages with a lot of bad code out there (e.g., PHP) will perform worse "

This is what tells me that AI's are not 'self improving'. If they could read a manual and understand it, then they should come up with better solutions. Not just regurgitate bad slop they learned from bad examples.

Who is claiming AI are self-improving, other than random low signal posts on the internet?

Maybe shouldn't say 'self improving', but 'able to make logical leaps beyond what they learned'.

That was one of the predictions that turned out to be wrong, though.

anecdotal: golang, with c or simplified modern c++

Reply on news.ycombinator.com