4 ms·

Most of these reasons apply to Java as much, if not more. It's an even more popular language with even more training data and also has a better type system so

by gf000 8mo ago

Most of these reasons apply to Java as much, if not more. It's an even more popular language with even more training data and also has a better type system so more validation on LLM output, etc.

EGreg 8mo ago
I wonder what people will say to that. I personally think neither Go nor Java would be good for "agents". Better to have them sandboxed in WASM.
- r_lee 8mo ago
  WASM isn't a language you'd want to program with. you can't verify outputs nor is there any proper training data aside from examples and such
- gf000 8mo ago
  Sandboxing is a completely orthogonal issue and WASM is probably not a good direct target for LLMs. Of course writing a language that compiles to Wasm is certainly a way, but you would have to sandbox also all the other tools that is used during development (e.g. agents can just call grep/find/etc).
yaseer 8mo ago
Except that Go is a simpler, smaller language than Java. That's one of the key points in the post.
- gf000 8mo ago
  More simplistic, not really simpler.
  - 3371 8mo ago
    I guess you misunderstood he meant simpler as in "easier"? Because I thought Something simplistic is simple...? Not an English native tho.
pants2 8mo ago
Certainly not the "one way to write it" idea. Java has a ton of language features.
- gf000 8mo ago
  Not really. It has a pretty bare bones OOP (single inheritance, interface), primitives and objects, generics and pretty much that's it. Newer features fit very nicely and didn't increase the language surface (records are just a normal class with some methods auto-generated, while sealed types are just a restriction on who can subtype an interface -- and yet these give full ADT support for the language that improves readability and type safety).
  - jimbokun 8mo ago
    Annotations add a seemingly infinite amount of new semantics. You can’t predict anything with confidence just looking at the code without also studying the annotation processors in depth, which regular Java tools don’t help you with.
    - gf000 8mo ago
      Well, that's just metaprogramming. Also, java annotation processors are strictly "append-only", they can't change code written as is. They may subclass it, or build new classes that make use of the annotations. In my experience LLMs are more than happy with annotations, especially from the widely used ones (spring/jakarta ee, lombok though it's not an annotation processor, etc). If you think about it, an annotation like @Path("/endpoint") is very informative for both humans and LLMs alike, being local to what it attaches to. Within an agent, the code serving the endpoint will be immediately visible in the context returned by a simple string search, no need to do another round of "find wherever this codebase registers routes".
      - Orygin 8mo ago
        Annotations are a scourge. Automagic extensions you have to understand through years of usage. Go has no such things and you have circled back exactly to the GP's point: "There's a ceiling on abstraction". There is no such ceiling in java ime
hu3 8mo ago
Java has decade(s) of cruft and breaking changes which LLMs were trained on. It's hard to compare. Plus Go compilation speed/test running provides quick iteration for LLMs.
- roegerle 8mo ago
  breaking changes? hardly.
  - hu3 8mo ago
    Yes, breaking changes. And many ways to do the same thing because the language kept evolving (thankfully).
  - nitwit005 8mo ago
    There is a decently long list of breaking changes now. Removing JavaEE modules from the JDK, and restricting sun.misc.Unsafe, are the ones people usually run into.
    - gf000 8mo ago
      These are relatively small-scoped library changes only though. Meanwhile Go already had a language change, while being less than half its age (loop variable capture).
      - nitwit005 8mo ago
        A long enough list of small changes eventually equates to a big change. People generally can't update applications from Java 8 or below to a new one without code updates.
        waynesonfire 8mo ago
        If hadoop did it, so can you. I'm talking about a project that stretched Java 8 to, and arguably beyond, its intended operational boundaries. Unlikely that you’re leaning on this boundary. It's Spring Boot upgrades that will be giving you troubles.
JimBlackwood 8mo ago
I mostly write Go code (and have barely had to write any code myself in the past months), but today I had to do some work in a Java project and Claude Code was a terrible experience. It really felt like using AI tooling of a year or two ago. It wasn’t understanding my prompts, going on tangents, not following the existing style and idioms. Maybe Claude was hungover or doesn’t like mondays, but the contrast with Go was surprising. One example is that I wanted to add an extra prometheus metric to keep track of an edge case in some for loop. All it had to do was define a counter and increment it. For some reason it would define the counter the line before increment it, instead of defining it next to the other counters outside of the for loop. Technically not wrong (defining a counter is idempotent), but who does that? Especially when the other counters are defined elsewhere in the same function? Anyway, n=1 but I feel it has an easier time with Go.
- gf000 8mo ago
  Well, there was a Claude outage today, maybe related :D My n=1 is that it is pretty good with Java, on par with other popular languages like Python and JS, in line with these 3 probably being a good chunk if not the majority of training data.
xannabxlle 8mo ago
Exactly, the propping up of Go seems unfounded. Java in it's newest iterations make it more compelling as a target, and people, especially young people, overlook it because of its stigma as enterprise cruft.
- anthonypasq96 8mo ago
  im a java guy, but it simply takes too long to start up and uses too much memory to be a reasonable language for ai agent development.
  - gf000 8mo ago
    "AI guys" use Claude CLI that renders to a terminal via freakin' react. Come on, java starts up fast enough and the memory usage can be set (better throughput vs less memory, it's a classic tradeoff. Go just defaults to worse throughput). Really, without some fat framework doing all kinds of initialization stuff, java code starts up practically instantly.
    - Orygin 8mo ago
      > Come on, java starts up fast enough and the memory usage can be set Yeah it can be adjusted, on the other hand you have a language that just works. Starts instantly and memory usage is bounded by usage, not guesstimate of how much the JVM will need. > Really, without some fat framework doing all kinds of initialization stuff, java code starts up practically instantly Have you many java projects that didn't use some fat framework? Good for you if you did, but 100% of java project I had the displeasure of touching were huge mess with deprecated frameworks on ancient java versions.
    - jim33442 8mo ago
      Java takes flags for min/initial/max memory that, as a strict law of nature, are always wrong the first time you try. And it holds onto unused memory unless you pass another flag. Idk exactly why there's no reasonable default for that, but probably cause it's in a VM. No other language has this problem.
seertaak 8mo ago
How are JVM startup times nowadays? Frankly the need to ship with a JVM (modulo graal admittedly) is a drawback, eg for CLI tools - which the author listed as a requirement. Go's static executable story, combined with it's competitive performance - without C++ or rust contortions - is a strong combo when your focus is on startup time and deployment simplicity. (If, otoh, I cared a lot about GC I'd definitely prefer Java - eg for non-fast algo trading.) Java is a fine language, tech stack, and ecosystem, but I agree with the author and parent commenter that this is a sweet spot for Go. Their decision to use it makes a lot of sense.
onoesworkacct 8mo ago
Think of the typical quality of Java that LLMs encounter vs the typical quality of Go. You've almost certainly got more experts-exchange.com than github.com
jen20 8mo ago
The points about tooling certainly do not apply to Java, for example, Maven vs Gradle (which is a huge mess in and of itself - do you use Kotlin or Groovy), and which plugins are you willing to pull in? Or is Ant still the thing? SpotBugs, Spotless? What test framework do you use? Do you use Mockito or one of the myriad alternatives? Go has _none_ of this nonsense, and it's better for it. Nor does Rust, FWIW, which IMO is also a better target language than Java for just about everything.
- cryptos 8mo ago
  Gradle could be used as an AI benchenmark on its own! The syntax of plugin DSLs changes all the time. Special credits could be achieved for handling old (Groovy) and new versions (Kotlin) of Gradle itself.

by gf000 8mo ago

Most of these reasons apply to Java as much, if not more. It's an even more popular language with even more training data and also has a better type system so more validation on LLM output, etc.

EGreg 8mo ago

I wonder what people will say to that. I personally think neither Go nor Java would be good for "agents". Better to have them sandboxed in WASM.

r_lee 8mo ago
WASM isn't a language you'd want to program with. you can't verify outputs nor is there any proper training data aside from examples and such
gf000 8mo ago
Sandboxing is a completely orthogonal issue and WASM is probably not a good direct target for LLMs. Of course writing a language that compiles to Wasm is certainly a way, but you would have to sandbox also all the other tools that is used during development (e.g. agents can just call grep/find/etc).

yaseer 8mo ago

Except that Go is a simpler, smaller language than Java. That's one of the key points in the post.

gf000 8mo ago
More simplistic, not really simpler.
- 3371 8mo ago
  I guess you misunderstood he meant simpler as in "easier"? Because I thought Something simplistic is simple...? Not an English native tho.

pants2 8mo ago

Certainly not the "one way to write it" idea. Java has a ton of language features.

gf000 8mo ago
Not really. It has a pretty bare bones OOP (single inheritance, interface), primitives and objects, generics and pretty much that's it. Newer features fit very nicely and didn't increase the language surface (records are just a normal class with some methods auto-generated, while sealed types are just a restriction on who can subtype an interface -- and yet these give full ADT support for the language that improves readability and type safety).
- jimbokun 8mo ago
  Annotations add a seemingly infinite amount of new semantics. You can’t predict anything with confidence just looking at the code without also studying the annotation processors in depth, which regular Java tools don’t help you with.
  - gf000 8mo ago
    Well, that's just metaprogramming. Also, java annotation processors are strictly "append-only", they can't change code written as is. They may subclass it, or build new classes that make use of the annotations. In my experience LLMs are more than happy with annotations, especially from the widely used ones (spring/jakarta ee, lombok though it's not an annotation processor, etc). If you think about it, an annotation like @Path("/endpoint") is very informative for both humans and LLMs alike, being local to what it attaches to. Within an agent, the code serving the endpoint will be immediately visible in the context returned by a simple string search, no need to do another round of "find wherever this codebase registers routes".
    - Orygin 8mo ago
      Annotations are a scourge. Automagic extensions you have to understand through years of usage. Go has no such things and you have circled back exactly to the GP's point: "There's a ceiling on abstraction". There is no such ceiling in java ime

hu3 8mo ago

Java has decade(s) of cruft and breaking changes which LLMs were trained on. It's hard to compare. Plus Go compilation speed/test running provides quick iteration for LLMs.

roegerle 8mo ago
breaking changes? hardly.
- hu3 8mo ago
  Yes, breaking changes. And many ways to do the same thing because the language kept evolving (thankfully).
- nitwit005 8mo ago
  There is a decently long list of breaking changes now. Removing JavaEE modules from the JDK, and restricting sun.misc.Unsafe, are the ones people usually run into.
  - gf000 8mo ago
    These are relatively small-scoped library changes only though. Meanwhile Go already had a language change, while being less than half its age (loop variable capture).
    - nitwit005 8mo ago
      A long enough list of small changes eventually equates to a big change. People generally can't update applications from Java 8 or below to a new one without code updates.
      - waynesonfire 8mo ago
        If hadoop did it, so can you. I'm talking about a project that stretched Java 8 to, and arguably beyond, its intended operational boundaries. Unlikely that you’re leaning on this boundary. It's Spring Boot upgrades that will be giving you troubles.

JimBlackwood 8mo ago

I mostly write Go code (and have barely had to write any code myself in the past months), but today I had to do some work in a Java project and Claude Code was a terrible experience. It really felt like using AI tooling of a year or two ago. It wasn’t understanding my prompts, going on tangents, not following the existing style and idioms. Maybe Claude was hungover or doesn’t like mondays, but the contrast with Go was surprising. One example is that I wanted to add an extra prometheus metric to keep track of an edge case in some for loop. All it had to do was define a counter and increment it. For some reason it would define the counter the line before increment it, instead of defining it next to the other counters outside of the for loop. Technically not wrong (defining a counter is idempotent), but who does that? Especially when the other counters are defined elsewhere in the same function? Anyway, n=1 but I feel it has an easier time with Go.

gf000 8mo ago
Well, there was a Claude outage today, maybe related :D My n=1 is that it is pretty good with Java, on par with other popular languages like Python and JS, in line with these 3 probably being a good chunk if not the majority of training data.

xannabxlle 8mo ago

Exactly, the propping up of Go seems unfounded. Java in it's newest iterations make it more compelling as a target, and people, especially young people, overlook it because of its stigma as enterprise cruft.

anthonypasq96 8mo ago
im a java guy, but it simply takes too long to start up and uses too much memory to be a reasonable language for ai agent development.
- gf000 8mo ago
  "AI guys" use Claude CLI that renders to a terminal via freakin' react. Come on, java starts up fast enough and the memory usage can be set (better throughput vs less memory, it's a classic tradeoff. Go just defaults to worse throughput). Really, without some fat framework doing all kinds of initialization stuff, java code starts up practically instantly.
  - Orygin 8mo ago
    > Come on, java starts up fast enough and the memory usage can be set Yeah it can be adjusted, on the other hand you have a language that just works. Starts instantly and memory usage is bounded by usage, not guesstimate of how much the JVM will need. > Really, without some fat framework doing all kinds of initialization stuff, java code starts up practically instantly Have you many java projects that didn't use some fat framework? Good for you if you did, but 100% of java project I had the displeasure of touching were huge mess with deprecated frameworks on ancient java versions.
  - jim33442 8mo ago
    Java takes flags for min/initial/max memory that, as a strict law of nature, are always wrong the first time you try. And it holds onto unused memory unless you pass another flag. Idk exactly why there's no reasonable default for that, but probably cause it's in a VM. No other language has this problem.

seertaak 8mo ago

How are JVM startup times nowadays? Frankly the need to ship with a JVM (modulo graal admittedly) is a drawback, eg for CLI tools - which the author listed as a requirement. Go's static executable story, combined with it's competitive performance - without C++ or rust contortions - is a strong combo when your focus is on startup time and deployment simplicity. (If, otoh, I cared a lot about GC I'd definitely prefer Java - eg for non-fast algo trading.) Java is a fine language, tech stack, and ecosystem, but I agree with the author and parent commenter that this is a sweet spot for Go. Their decision to use it makes a lot of sense.

onoesworkacct 8mo ago

Think of the typical quality of Java that LLMs encounter vs the typical quality of Go. You've almost certainly got more experts-exchange.com than github.com

jen20 8mo ago

The points about tooling certainly do not apply to Java, for example, Maven vs Gradle (which is a huge mess in and of itself - do you use Kotlin or Groovy), and which plugins are you willing to pull in? Or is Ant still the thing? SpotBugs, Spotless? What test framework do you use? Do you use Mockito or one of the myriad alternatives? Go has _none_ of this nonsense, and it's better for it. Nor does Rust, FWIW, which IMO is also a better target language than Java for just about everything.

cryptos 8mo ago
Gradle could be used as an AI benchenmark on its own! The syntax of plugin DSLs changes all the time. Special credits could be achieved for handling old (Groovy) and new versions (Kotlin) of Gradle itself.