I'm a Java developer by day and have also delivered production codebases in Python and Scala. Before that I worked in ETL with Informatica. I've been building systems professionally for quite a while.
I’ve tried LLM-assisted development across Java, JavaScript, Python, Rust, C++ and Go. The difference in how well models hold the system in their “head” becomes obvious once the codebase grows beyond a few thousand lines.
With most ecosystems the entropy explodes. Python and TypeScript in particular have an enormous combinatorial space: frameworks, build systems, typing styles, dependency patterns, project layouts. Two codebases solving the same problem can look completely different. That variability leaks directly into the training distribution and the output starts to drift.
Go sits at the opposite end of that spectrum.
There’s basically:
one formatting style
one standard build system
one dependency mechanism
one dominant project layout
a very small set of concurrency primitives
a language that has barely changed in a decade
That constraint is exactly what LLMs thrive on. The solution space is narrow, so the model converges instead of wandering.
In my own experiments, once a codebase passes ~8k lines, most languages start to show cracks: incorrect imports, wrong framework idioms, subtle API hallucinations. With Go the agents stay coherent much longer. The tooling helps too — extremely fast builds, deterministic formatting, and batteries-included tooling mean the feedback loop is tight.
Java often gets suggested as an alternative because it’s statically typed and mature. But in practice the ecosystem is a maze: Maven vs Gradle, Spring everything, annotation magic, layers of frameworks, multiple architectural styles. The language may be stable, but the surrounding universe isn’t.
I’m also a big Rust fan. If you actually need Rust’s capabilities it’s fantastic. But it’s slower to compile and significantly more complex for LLMs to work with. Beyond small codebases the difference becomes obvious.
One final point: architecture matters as much as language. Strong modular boundaries, API-first feature access, and good code maps help enormously when working with LLMs.
Used carefully, these tools are a serious productivity multiplier. The interesting question now isn’t whether they work - it’s which languages and system designs allow them to work reliably.
I’ve tried LLM-assisted development across Java, JavaScript, Python, Rust, C++ and Go. The difference in how well models hold the system in their “head” becomes obvious once the codebase grows beyond a few thousand lines.
With most ecosystems the entropy explodes. Python and TypeScript in particular have an enormous combinatorial space: frameworks, build systems, typing styles, dependency patterns, project layouts. Two codebases solving the same problem can look completely different. That variability leaks directly into the training distribution and the output starts to drift.
Go sits at the opposite end of that spectrum.
There’s basically:
one formatting style one standard build system one dependency mechanism one dominant project layout a very small set of concurrency primitives a language that has barely changed in a decade
That constraint is exactly what LLMs thrive on. The solution space is narrow, so the model converges instead of wandering. In my own experiments, once a codebase passes ~8k lines, most languages start to show cracks: incorrect imports, wrong framework idioms, subtle API hallucinations. With Go the agents stay coherent much longer. The tooling helps too — extremely fast builds, deterministic formatting, and batteries-included tooling mean the feedback loop is tight.
Java often gets suggested as an alternative because it’s statically typed and mature. But in practice the ecosystem is a maze: Maven vs Gradle, Spring everything, annotation magic, layers of frameworks, multiple architectural styles. The language may be stable, but the surrounding universe isn’t.
I’m also a big Rust fan. If you actually need Rust’s capabilities it’s fantastic. But it’s slower to compile and significantly more complex for LLMs to work with. Beyond small codebases the difference becomes obvious.
One final point: architecture matters as much as language. Strong modular boundaries, API-first feature access, and good code maps help enormously when working with LLMs.
Used carefully, these tools are a serious productivity multiplier. The interesting question now isn’t whether they work - it’s which languages and system designs allow them to work reliably.