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

reply
TIMTOWTDI strikes back.
reply
Why use Go when you can use Rust?
reply
So I can test my feature today instead of waiting until it finishes compiling tomorrow.
reply
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.

reply
> but it can be worked around by preplanning crates.

Maybe if you're working alone.

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

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

reply
In short, compile times and a more full-featured stdlib
reply
Doesn't Rust have long compile times? Does Go suffer from the same problem?
reply
One of the design goals of Go was to be fast to compile. And they achieved it.
reply
Go famously has stupidly fast compile times.
reply
Because LLMs are better at Go? And because some people understand Go code easier and they might want to look at the code?
reply
why,i have same question
reply
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
reply
>which could be more fun if you’re running CI checks 50 billion times

Even running them 5 times it's WAY more fun

reply
why use Rust when you can use Zig?
reply
Why use zig when you can use odin?
reply
>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.

reply
Why? Go has a GC, is basically incompatible with C and very limited overall
reply
Go's limited syntax is actually a feature here,because it stops the LLM from trying to be too clever
reply
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

reply
'incompatible with C' isn't a serious problem nowadays and won't be a problem at all in a couple years.
reply
CGO exists.
reply
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.

reply
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?
reply
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.
reply
>Go has a huge stable standard library no other language even comes close to

Well, Java and Python do.

reply
Yet the first thing most people do before making a HTTP request is pip install requests
reply
Yet, a nicer request wrapper is not the be all end all of batteries, and Python covers a huge spread of libs
reply
> Go has a huge stable standard library no other language even comes close to.

Java, C#, Python, Node.

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

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

reply
I picked Go because it tends to use fewer resources than Node.js, and startup time is quite fast.
reply
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.
reply
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.
reply
Go is statically typed but the type system leaves much to be desired.

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

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

reply
Performance? Second only to rust and other lower level langs. Surely you don't need this spelled out for you...
reply
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.

reply
Java and C# are there and faster.
reply
Yes, but kids these days only consider JS, Python, Rust and Go.
reply
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?

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

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

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

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

reply
deleted
reply
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.
reply
don't you worry about garbage collection?
reply
If you were using Python, then probably not.
reply
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.
reply
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
reply
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.

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

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

reply
deleted
reply