That’s what I’ve settled on. Python is so flexible that there are a million ways to organize code, pass arguments, etc. If you already have a code base to work from, an LLM can make new code in the style of the old code. But a fresh project? Once you get to a certain level of complexity it quickly can turn into write once, read never code (even if the code is passing tests).

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.

TIMTOWTDI strikes back.

Why use Go when you can use Rust?

1. Amount of Rust training data isn’t as much as Go.

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.

This must really depend on your niche. I assume you do web stuff or something? Good luck finding any golang examples in a lot of other fields. Rust, on the other hand, is taking over the world in systems programming.

Been reading and drinking that kool-aid for some time until I realized it's just an internet bubble mumbo jumbo. Majority of systems are still written in C and C++, and will be for unforeseeable future.

>Good luck finding any golang examples in a lot of other fields.

There are go examples (and full blown programs) for anything, from servers to Kubernetes and Docker.

which is pretty much webdev for the larger industry.

Yes. Maybe I should have said web stack?

Just reporting what I’ve experienced. No need to go with the ad hominem attack. I happen to lead a team with a major Rust infra project and I stand by the experience with usage across all the LLM models.

What ad hominem?

In short, compile times and a more full-featured stdlib

Doesn't Rust have long compile times? Does Go suffer from the same problem?

Go famously has stupidly fast compile times.

One of the design goals of Go was to be fast to compile. And they achieved it.

why,i have same question

I’m heavy into rust and never really use golang, but one big benefit of go over rust is compile times are significantly quicker, which could be more fun if you’re running CI checks 50 billion times

>which could be more fun if you’re running CI checks 50 billion times

Even running them 5 times it's WAY more fun

Because LLMs are better at Go? And because some people understand Go code easier and they might want to look at the code?

why use Rust when you can use Zig?

Why use zig when you can use odin?

So I can test my feature today instead of waiting until it finishes compiling tomorrow.

this is the top reason for a reasonably complex project, but it can be worked around by preplanning crates.

the other reason is if you really want async as is in vogue nowadays, function coloring - but this is rapidly becoming irrelevant, see article.

> but it can be worked around by preplanning crates.

Maybe if you're working alone.

Yup, adopting Go is exactly what I've done too.

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.

But what is the selling point for Go? I get that it is allegedly hailed to be a simple language with basically no batteries included, but why is that a selling point? Does Go excel at anything no other language does?

Performance? Second only to rust and other lower level langs. Surely you don't need this spelled out for you...

Not just performance, but static typing and prevalent in the training data/easy for LLMs to reason about.

Of course, your response admits, "second to Rust", which I am guessing is an unspoken question in the grandparent's mind.

Java and C# are there and faster.

Yes, but kids these days only consider JS, Python, Rust and Go.

If performance is the main difference, whatever that means, then basically Go should be reserved for when Rust and other lower level langs cannot be used due to some other constraint? Are we mainly talking about performant Web backends?

Say I am building some app that I know will be CPU-bound, why choose Go over say... Swift?

> 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.

>If performance is the main difference, whatever that means, then basically Go should be reserved for when Rust and other lower level langs cannot be used due to some other constraint?

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.

I think that’s sort of the selling point no? It’s really boring. It has like -10 keywords, compiles insanely fast, and has a concurrency model that’s easy to use and read. LLMs are great at using Go tooling to sanity check along the way. It’s easy to write shitty Go but it’s really pleasant to work with if you find those things compelling.

don't you worry about garbage collection?

If you were using Python, then probably not.

haha exactly. I’m coming from Swift, and I don’t want to go back to manually releasing objects like I used to in ObjC, let alone reason about lifetimes.

What's the big issue with GC nowadays? It has mattered to me exactly once in decades and it was still manageable anyway by using a more low level style in a hot loop. I see very few usecases where GC actually matters and for those rare few cases it was not like you were using python beforehand anyway

Why the hell would he "worry about garbage collection"? That kind of thing is a cargo cult fear.

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.

For one thing it’s statically typed and has many fewer foot guns than Python, so the llm-produced code is more likely to do what you expect.

Go is statically typed but the type system leaves much to be desired.

Go’s benefit are primarily around simplicity, readability, and concurrency.

>Go is statically typed but the type system leaves much to be desired.

Not that much. Looking at Rust or Haskell complexity, I don't really desire it.

Python has much better type system than Go, I don’t know what you’re on. With Trio it has a better async capabilities too.

No batteries!? Go has a huge stable standard library no other language even comes close to. Built in tooling for unit testing, performance testing, debugging, code formatting, package management, etc. And most go binaries can be compiled statically so libc is not even a dependency. Golang is the definition of batteries included.

>Go has a huge stable standard library no other language even comes close to

Well, Java and Python do.

Yet the first thing most people do before making a HTTP request is pip install requests

Yet, a nicer request wrapper is not the be all end all of batteries, and Python covers a huge spread of libs

Python has a quite random collection of stuff, and it's often quite low quality and people don't use it anyway. I wouldn't say it is close to Go.

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.

>Python has a quite random collection of stuff, and it's often quite low quality and people don't use it anyway. I wouldn't say it is close to Go.

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.

> 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.

> I haven't used Java for a decade or so but as I recall its standard library was pretty bare bones (similar to Rust).

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`).

C# (.NET) would probably be the winner here. Go standard library is rather minimalistic compared to it.

> Go has a huge stable standard library no other language even comes close to.

Java, C#, Python, Node.

Not my words, lol. It's what people say about the language. But thank you, this was the type of answer I was looking for.

I picked Go because it tends to use fewer resources than Node.js, and startup time is quite fast.

I've never used Node, so I can't judge it. I'm still stuck in the C# world. So, I am curious how Go performs in comparison. I'll need to do some research.

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.

I don’t have any head-to-head comparisons of the same app written in both languages. I can compare apps with similar functionality: listening to GitHub web hooks vs. Linear web hooks. Both are deployed to Kubernetes.

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.)

>I get that it is allegedly hailed to be a simple language

That might be its core feature if you do agentic coding.

Go has a very full featured standard library.

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.

> (do you really ask why that's a selling point?)

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.

Fun it is not.

    if err != nil

It's amazing how they managed to design a new language with all the flaws of '90s languages.

Even that is fun. A little tedious, but straighforward, no compiler magic.

1. It has first-class co-routines, so supports high concurrency without having to deal with async bullshit

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

I really don't like the lang itself but nobody will deny it has a very strong ecosystem and stdlib for handling around 95% of many well-solved problems you are likely to encounter.

goroutines make building scalable network (web) servers trivial and fast. I'm not a big fan of the language, but the runtime is fantastic.

Golang truly excels at cross compiling.

Why? Go has a GC, is basically incompatible with C and very limited overall

Go's limited syntax is actually a feature here,because it stops the LLM from trying to be too clever

LLMs use `any` types, `recover`, `init`, and other weird warts of golang

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

CGO exists.

uh huh, how's the trampoline working out?

'incompatible with C' isn't a serious problem nowadays and won't be a problem at all in a couple years.

or the language was fundamentally designed to make mid level engineers more productive...

>Just use Go. LLMs have seen a ton of it, they write it well, it compiles practically instantly, and it has all the advantages of a typed compiled language.

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.

Also there are still considerations like domain, team expertise, org ecosystem etc. to consider. I love to use Rust for most things, but now I'm working with an org that primarily has expertise in Java, and I'm not going to rock the boat for barely any reason. Python is also still useful for most ML stuff, and Django is quite a pleasure to work with (although it wouldn't be my first choice).

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.

Same here, working with a team that knows Java, so I'm letting Claude write Java.

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.

>the LLM constantly guesses arguments or dictionary formats wrong [...] it's better to avoid that whole class of runtime errors altogether.

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.