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.
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.
Meanwhile Go already had a language change, while being less than half its age (loop variable capture).
Plain vanilla java code is really backwards compatible, on both a syntax, and on a binary level.
You can often find decades old jars on some random university site, working with JDK 25 with no issue.
Sorry, couldn’t help myself.
How is Java slow in any of these? Plenty of tricks e.g. AppCDS before the tests.
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).
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".
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
There is no case where annotations are superior to the meta programming facilities built into the language proper. Annotations only became popular because Java didn’t have easy syntax for function references or anonymous functions for a very long time.
Also, hard disagree on "register" method being simpler. A register method is code, while an annotation is a static declaration, ergo data. The former can happen in a helper function, renaming it from "register" to "path", changing/modifying the parameters, or putting it into some while loop dynamically generating endpoints.
At the very extreme it is Turing complete to figure out what endpoints are registered.
The annotations are static, yeah. That's one advantage. I would still rather not do that. A lot of people were happy not to need that anymore in like NodeJS.
And old code continuing to run 10 years later is a huge value of the platform.
Mostly old code will keep working, but there are exceptions like Python 2->3 breakage that deserves all the criticism it got.
Code is data.
Data is code.
Biggest thing was lack of cooperative multitasking until virtual threads (Project Loom). And much older, lack of lambdas before Java 8.
I personally think neither Go nor Java would be good for "agents". Better to have them sandboxed in WASM.
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).
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.
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.
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.
And it's not really a VM in that sense of the word. It's a runtime, Go also has such a runtime it's just bundled.
But still nobody wants to use it given the choice, because it sucks. 75% of the code you write is boilerplate mainly thanks to OOP, the com.foo.bar stuff is an eyesore, and it somehow uses even more RAM than Python. That's without getting into the enterprise cruft land where each method has 3 annotations on it, where the annotations themselves are maintained by an entire outsourced team.
75% boilerplate, come on. It has records and pattern matching now. Many of the cases of boilerplate are strictly self inflicted. And this criticism is absolutely laughable in a thread about Go, where you have to repeat some error ritual every 3 lines, losing the signal in all the noise. Java is a much more concise language than Go.
com.foo.bar solves a very real issue that is a big problem in e.g. the Node and Rust ecosystem (package name squatting).
And it uses as much RAM as you set it to use. It's true of every managed language that more memory equals less work to do, that is better throughput. But Java's GCs are the state of the art, it will work just fine with half the pre-configured memory.
The Go error handling is bad enough that it makes the lang not a top choice for me. Seems like entire vision of Go was being the opposite of C++ in every way, and that resulted in something halfway decent, but it unfortunately doesn't use exceptions. You get stuff done in fewer loc than in Java at least, and it always had solid m:n greenthreading, and the GC just works without having to tune it.
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.
You've almost certainly got more experts-exchange.com than github.com
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.
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.