5 ms·

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", an

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.

JodieBenitez 2mo ago
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.
- win311fwg 2mo ago
  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.
YuechenLi 2mo ago
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.
- bob1029 2mo ago
  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.
  - YuechenLi 2mo ago
    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.
kpw94 2mo ago
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 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?)
- 9rx 2mo ago
  > is Zig the closest to filling that niche? Given what you said about Go, presumably that is Solod (https://solod.dev https://solod.dev)
  - kpw94 2mo ago
    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?
dosisking 2mo ago
> 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.
- ethersteeds 2mo ago
  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.
  - otherme123 2mo ago
    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".
  - KptMarchewa 2mo ago
    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.
  - mrighele 2mo ago
    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 https://en.wikipedia.org/wiki/Zen_of_Python
fulafel 2mo ago
You can rather easily ship Clojure apps as single binaries, eg with this: https://github.com/avelino/jbundle https://github.com/avelino/jbundle
jgoodhcg 2mo ago
I’ve gone down the same logical pattern of using Go for llms even though I personally prefer Clojure.
- foretop_yardarm 2mo ago
  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)
agentcoops 2mo ago
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.
- cryptos 2mo ago
  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.
- zem 2mo ago
  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.
bezko 2mo ago
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.
transdev12 2mo ago
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.
- packetlost 2mo ago
  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

JodieBenitez 2mo ago

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.

win311fwg 2mo ago
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.

YuechenLi 2mo ago

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.

bob1029 2mo ago
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.
- YuechenLi 2mo ago
  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.

kpw94 2mo ago

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

9rx 2mo ago
> is Zig the closest to filling that niche? Given what you said about Go, presumably that is Solod (https://solod.dev https://solod.dev)
- kpw94 2mo ago
  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?

dosisking 2mo ago

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

ethersteeds 2mo ago
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.
- otherme123 2mo ago
  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".
- KptMarchewa 2mo ago
  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.
- mrighele 2mo ago
  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 https://en.wikipedia.org/wiki/Zen_of_Python

fulafel 2mo ago

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

jgoodhcg 2mo ago

I’ve gone down the same logical pattern of using Go for llms even though I personally prefer Clojure.

foretop_yardarm 2mo ago
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)

agentcoops 2mo ago

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.

cryptos 2mo ago
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.
zem 2mo ago
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.

bezko 2mo ago

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.

transdev12 2mo ago

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.

packetlost 2mo ago
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