Why Go is an Ideal Language for AI-Assisted Software Engineering
6 points by yawaramin
6 points by yawaramin
Here is the take of Rob Pike, one of the creator of Go, on AI:
Fuck you people. Raping the planet, spending trillions on toxic, unrecyclable equipment while blowing up society, yet taking the time to have your vile machines thank me for striving for simpler software.
Just fuck you. Fuck you all.
I can't remember the last time I was this angry.
I think it's important to include the context of that email/post, which was that he was cold emailed by a bot with some inane "thank you" email from some huge AI bot farm thing.
Individual employee at large corp has different opinion about something than others at large corp. Something that’s never happened before 😉
The thing is, I would say most software engineers get into software engineering because we like programming. It might be the case that using AIs shifts the work from writing code to reviewing code, but that is substantially less rewarding and enjoyable work. Capitalism kills the artisan, once again.
The thing is, I would say most software engineers get into software engineering because we like programming.
How confident are you of this? I'm sure it's true of the people on this site, but I often wonder if for every one of us there's a handful that got in to the profession mostly because it had decent pay and working conditions.
Well, I can't speak for the psyche of every software engineer, but I think doing a job where you're not particularly interested in the work but like the pay and conditions is a path to dreary self-unfulfilment -- and until AIs, I'd say actually writing code was the staple work of the software engineer. (As the article points out, of course, it's more than just programming, but I'd say nobody really becomes an SE because they love reviewing code or team management or whatever.)
If the working conditions and pay didn't pull you into the field - it certainly has kept a lot of developers developing because of them.
Or to phase it differently, there are many people who wanted to achieve something that required writing code in the past, but did it for various reasons. Now the requirement of writing code is removed, so different goals have clearer division.
Look, I love go, but this is just pure marketing drek
Yeah, it's a lot of nicely polished text listing features. But once you look at benchmarks: it's not preferred https://arxiv.org/html/2503.17181v1 it's not the best https://arxiv.org/pdf/2505.13004 it's not even efficient https://martinalderson.com/posts/which-programming-languages-are-most-token-efficient/ (yes, some of those are old - feel free to list new ones with different outcomes)
Go compiles directly to a single, static binary with zero system dependencies
Huh, not even libc? That's actually pretty cool then.
As for the rest of the article, for me ADTs-and-patternmatching-esque languages are much more pleasant to read/maintain/refactor and I don't think a programming language should be made to please a model, if anything the reverse.
Also many are making the claim, on the socials at least, that their $fav_lang is an ideal LLM language(Lean, Rust, TypesScript, Elixir) that I'm not sure what to think of it.
Ultimately, AI is your newest teammate
yuck.
Generally, go links to libc, since you can't statically bundle glibc (due to NSS) and one notable platform (OpenBSD) kills your process if it tries to make syscalls from outside of libc. However apparently you can make it do a fully static binary on Linux with some flags and/or by using musl.
"Go is for Software Engineering" - unlike all those other silly programming languages? What?
The elephant in the room is of course Rust.
The general sentiment seems to be that a strong type system compensates the shortcuts AI tends to take.
I mean the article is corny af, but I think the core argument is legit. If generating code gets cheaper, then fast feedback, deterministic tooling, strong typing, simple semantics and easy verification become more valuable (even if less enjoyable). You can argue whether Go is uniquely good at those things, I think it is, but much of this thread seems to be arguing with AI existing rather than with what the article says. :)
I do think it behooves language designers to more heavily prioritize how code reads over how it writes in this age of code written by no one (but I was on about this before LLMs as well, so perhaps I'm just interpreting new developments as supporting my existing opinions).
That said, Go has never struck me as a language that is particularly easy to read, especially in cases where you don't already know the code to be correct. Go has some neat dynamic tooling for this (go test -race, notably), but really falls down in statically letting code establish its own guarantees. Also, and perhaps this is just an aesthetic thing I'll get over someday, the boilerplate (especially e.g. in error handling) makes it hard for me to actually trace through the important logic.
At this point in time, shouldn't we acknowledge that the ideal language for LLMs is whatever language there's the most source code available for? My first guess would be Python, since I've seen LLMs generate Go code that looks for all the world like a nearly literal transcription of Python.
Experience also says that largest source code corpus wins. Try to get an LLM to generate code for the GPP general purpose preprocessor (https://github.com/logological/gpp/) and you'll see that in action. Asking for troff macros to do something fancy is also a way to test this.
This phenomenon suggests a test for AGI: specify a previously unimplemented language via a grammar (BNF or something). Can an "AI" write a quine in that language?
shouldn't we acknowledge that the ideal language for LLMs is whatever language there's the most source code available for?
More deterministic correctness from tooling makes more sense to me. With a non-deterministic system writing code, I want the strongest possible guarantees on the output.
To me it seems that the more source code there is out there, the more chances of lots of it being wrong/old/un-idiomatic in some way, so results would probably be mixed. Go code is quite uniform as noted in the article.