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.

▲

hu3 2 hours ago | parent | next [-]

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 2 hours ago | parent [-]

breaking changes? hardly.

▲

nitwit005 an hour ago | parent | next [-]

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 33 minutes ago | parent [-]

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 18 minutes ago \| parent [-]
		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.

▲

hu3 2 hours ago | parent | prev [-]

Yes, breaking changes. And many ways to do the same thing because the language kept evolving (thankfully).

▲

xannabxlle 2 hours ago | parent | prev | next [-]

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.

▲

pants2 2 hours ago | parent | prev | next [-]

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

▲

gf000 2 hours ago | parent [-]

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 30 minutes ago \| parent [-]
		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.

▲

EGreg 3 hours ago | parent | prev | next [-]

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.

	▲	gf000 2 hours ago \| parent \| next [-]
		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).
	▲	r_lee 2 hours ago \| parent \| prev [-]
		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

▲

yaseer 2 hours ago | parent | prev | next [-]

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

	▲	gf000 2 hours ago \| parent [-]
		More simplistic, not really simpler.

▲

JimBlackwood 2 hours ago | parent | prev [-]

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 an hour ago \| parent [-]
		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.