I created a big Python codebase using AI, and the LLM constantly guesses arguments or dictionary formats wrong. Unit tests and stuff like pydantic help, but it's better to avoid that whole class of runtime errors altogether.
This is where I’ve found that a compiled, strongly typed language (any one really) works well with an LLM. With the little bits of friction that is part of writing a language like Go, the LLM can produce pretty decent (and readable) code.
2. Golang syntax and style is very verbose yet simple. There’s not as many options nor programming language to domain mapping needed as in Rust. Leads to needing less sophisticated LLM to spit out Golang than Rust successfully and efficiently.
There are go examples (and full blown programs) for anything, from servers to Kubernetes and Docker.
the other reason is if you really want async as is in vogue nowadays, function coloring - but this is rapidly becoming irrelevant, see article.
Maybe if you're working alone.
Even running them 5 times it's WAY more fun
Well, Java and Python do.
I haven't used Java for a decade or so but as I recall its standard library was pretty bare bones (similar to Rust).
Apparently C# has a pretty comprehensive standard library but I've never used it.
I use C# more days than not. The comprehensive standard lib is impressively large and accomplished everything I need. Third-party libraries is a real pain point though. I haven't looked in sometime, but things like sane PDF libraries, reporting libraries, etc. were severely lacking when I needed them last. As much disdain as I have for Java, I think it is better in that regard.
People who came into Python for ML and Data Science, and just care for their array and ML libs maybe.
But long time Pythonistas absolute use Python's standard library - and it's hardly "quite low quality". "Batteries Included" is one of the community slogans.
Even a decade ago (and more) the collections library in the Java standard lib was second to none. It's standard lib only got better since then (e.g. `HttpClient`).
Java, C#, Python, Node.
It's simple (do you really ask why that's a selling point?)
It's fast to compile.
It's fast to run.
It's good with parallelism.
It has myriads of examples, and LLMs can pick it up well too.
It has good backing.
It has good tooling.
It's fun.
It statically compiles to a trivially deployable binary.
It's excellent at cross compiling.
It has good adoption.
Yes. Assembly languages are simple, but that does not mean they easy to use well.
Fast to compile? A nice to have but not a requirement of mine. Parallelism is nice, but not something of value in my current project. Perhaps the next though!
I do like the LLM ease. It's make learning the language n times faster.
I can get behind the good backing, tooling, fun, and ease to deploy.
Hmm, I am supposed to be working on a game for a friend soon. I was going to go with C#, but I might play with Go and see how that goes.
if err != nil
2. It produces a dependency-less statically linked binary
3. Duck typed interfaces give you static typing with minimal ceremony. They are implemented even for types outside your own code base, which is a common pain point in Java or C#.
4. It compiles quickly
Though, it was a slap in the face for a lot of C#-ers when Go beat out C# for the Typescript compiler rewrite. I personally do not mind because C# is my Enterprise language, but it's not my favorite language or anything.
The GitHub listener written in Go has a CPU limit of 50m, but actual usage of 10m. Memory consumption is around 34MB of a 64MB limit.
The Linear listener written in Typescript consumes around 20m/250m CPU, but 235MB/500MB memory.
The 2x CPU and 9-10x memory consumption is significant, especially as we scale usage or add services.
(Yes, I know we need to do more right-sizing.)
Go’s benefit are primarily around simplicity, readability, and concurrency.
Not that much. Looking at Rust or Haskell complexity, I don't really desire it.
Of course, your response admits, "second to Rust", which I am guessing is an unspoken question in the grandparent's mind.
Say I am building some app that I know will be CPU-bound, why choose Go over say... Swift?
Language religious wars are silly: you should choose a language based on your constraints and personal tastes. If there's no clear advantage of one language over another for a given task - then all the options are viable, pick one and get on with solving the problem.
Or when performance is the main but not the only difference, and there are many other benefits.
>Say I am building some app that I know will be CPU-bound, why choose Go over say... Swift?
Because unless you're building for macOS/iOS, Swift is really a no-go, with lackluster support for other platforms. Plus slow to build and convoluted.
That might be its core feature if you do agentic coding.
Garbage collection is not an issue for 99% of programs. And for those that it is, there are ways to mitigate the issue (e.g. there are extremely high performance trading system written in Java, where every last sub-millisecond counts).
Blanket fear of GC reminds me when new programmers learned about how assembly is lower level and can be faster, and wondered why everything is not written in assembly.
Use Mypy in strict mode and run it in the post-turn hook of your LLM harness so the LLM has no choice but to obey it. And don't use overly general dictionary types when the keys are known at development time; use TypedDicts for annotations if you must use dicts at runtime.
rust is a better language in every way for LLMs: more precise typing, better compiler errors, fewer performance footguns, no race conditions, clear interface definitions and implementations
golang is easier for humans to quickly get productive, but the language is lacking in helpful features for an LLM
Or any of the faster typed languages you are most comfortable with, as you might need to look at the code some times. LLMs are great at writing and understanding C# and Java.
The great thing about LLM-assisted coding is that an experienced software engineer can acquire decent familiarity with a language quite quickly. And then has a useful sparring partner for understanding and using the quirks and features of a new language.
If I compare the results to another team that uses Python with Claude I see slightly better results on the Java side. Not because Claude knows that better, but because the tools are more rigid by default which creates more of a self correcting loop for Claude. The Python side has Pydantic, but it's a bit of an afterthought, while in Java you can't skip the type checking.
In the end you can do the same things on both sides, it's 95% a team/engineering culture difference. So pick the language that the team knows best.
Typed, garbage collected, fast to compile and run, stdlib that includes just enough to work out of the box. I really don't like writing it by hand but for the LLM it's perfect.