Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I really don't agree. I'm not hear to evangelize rust but by using enums from DB to templates and writing the code to make it consistent my experience with LLMs is infinitely better than golang for consistency and you have to include a lot more context to make golang work without issues whenever things are operating on chans or workgroups.by boredumb
- Who cares? Languages are tools, LLMs are tools. Use the ones more appropriate for what you are trying to do.
Is Go better than CSS if you are doing web layouts? Is it better than zig if you are outputting minimal wasm deliverables? Is it better than swift if you are doing iOS specific development? Is it better than bash for OS scripting?
Think about what you are doing and choose appropriately. This was true before LLMs.
Are you having fun? Chose LISP then
by hugodan - How dare you suggest having fun! Pay attention! We’re trying to have a language flame war here!
- > Who cares? [sorry, but that question is trolling]
People who want to use the most appropriate tool.
> Use the ones more appropriate for what you are trying to do.
What they are trying to do is find a programming language that LLMs work well with.
> So you are using Go with LLMs for the objective and destination of token consumption for token consumption sake?
The trolling gets more intense with each comment ...
P.S. Someone else responded:
> But this isn't a user story. The user story is what you should be picking the tool for.
I don't see how this is at all relevant to my comments. I'm certainly not going to argue about what some other party should or should not be doing.
by jibal - The article is about which tool is more appropriate, and you're dodging that question. Every use case has multiple langs you could use for it, and there's no universally agreed-upon choice. Like if you're writing a typical web API backend with LLM assistance from scratch, which do you use between JS, Py, Java, Go, Rust, etc?by frollogaston
- Been doing bash scripting for years. Tried Go recently, on my, it’s so much better for everything OS scripting. I regret I haven’t started with Go years ago. All my scripts are rewritten to Go. I kept only a handful, those that are just a few lines and no logic.by wltr
- > Is it better than zig if you are outputting minimal wasm deliverables?
Which tradeoffs are you willing to accept? Zig (along with several other languages) is superior in a lot of ways for that type of job, but I still settled on Go for a particular minimal WASM (browser) project. It wasn't my first choice, but it was where I ended up because LLMs kept going out to lunch in other languages and I didn't have anywhere close to the required budget to write it by hand. I read some comments like these about Go in the past so the Go attempt was mostly a contrarian Hail Mary after so many previous failed attempts in more technically well suited languages and... it worked! Shockingly well.
It still isn't my first choice for it, but having something useful with happy users beats technical imperfection every day of the week as far as my needs go. Go really did show its worth as an LLM target for that particular workload. Whether or not that is reproducible for any other project remains to be seen, but there seems to be a growing sentiment that echos the same. There just might be something to it.
by win311fwg - > Who cares? Languages are tools, LLMs are tools. Use the ones more appropriate for what you are trying to do.
The article specifically discusses how Go is well-suited for LLMs. It's not going on about general programming topics.
by runjake - I wouldn't take language advice from a Product Manager and Chief Evangelist from anywhere - and especially not Google.
Having said that: my opinion is that LLMs thrive by working in a tight loop. Unlike a human, they thrive with more and tighter constraints (and the better models are obviously far better in this regard).
I want to ditch the things that made writing code easier due to the limitations of humans, and embrace something that an LLM can leverage for better results. For me that means: an especially rich type system, (ideally pure) functional code, efficient systems-level performance and leanness. Good error messages that guide the LLM incrementally.
Go does not provide much in the way of those 3 desires, so calling it "ideal" with nothing aside from anecdotes to back that up is not compelling.
by switchbak - I can’t say much for a Chief Evangelist, but the Product Manager certainly has quite the C.V.by fractorial
- I keep seeing these language specific proclamations, and they are annoying and reek of inexperience to me.
I’ve had a great time doing LLM assisted coding in Zig, and it seems comparable to the generic Typescript/React I do at work.
I don’t doubt simplicity and good PL design pay dividends, but everyone’s favorite language can’t be the silver bullet in our new LLM world. Things just don’t add up, and I keep seeing it for Erlang, Gleam, Lisp, C, Rust, Go, TypeScript, Python, etc.
And to pick on Go a little bit, I don’t think it has any unique qualities that make it better for LLMs, where I think you could make that argument for other modern languages that offer new features leveraging their compilers and enforcing more correctness guarantees.
by rudedogg - > leveraging their compilers and enforcing more correctness guarantees.
The counter argument here is that these checks cause slower compile times and were designed to prevent common mistakes humans make.
If models get good, they may not need the same checks human written code needs. For example, frontier models already will virtually never produce a typo.
Humans need time to think, but a model’s bottleneck is in how quickly it can verify its work. Slower compile times hurt a models ability to iterate.
I don’t think we’re there yet (and we may not get there). But there is an argument to be made that languages with faster compile times may be better for LLMs in the long run than languages with strong checks but slow compilation.
- do people actually claim LLMs are good with Lisp? all i've seen recently are people frustrated that their model can't seem to balance parentheses.by bygosh
- compilation time is massively important for developing with agentsby anthonypasq
- I'd argue Go is not on a "Pareto frontier" and that no matter how you value the various attributes of programming languages, a fair assessment will never select Go.
A simple example is: if you highly value language popularity; Go is not most popular. If you highly value a type system that catches errors; Go's type system catches fewer errors than others. Etc. There is no weighted sum of attributes that will select Go--that's my argument.
by Buttons840 - Uh compile time and linting efficiency, lightweight runtime, gc.
There’s no equivalent competitor, it’s the best if u want to just write lots of undifferentiated code.
To caveat this if u want to run about 50 agents or so in parallel, all the typescript projects burn ur disk via node modules. The rust ones take forever to compile and burn too much compute
by aabdi - Simple toolchain which supports trivial lightweight deployment is my go to attribute to select Go in projects.by groestl
- Pareto frontier means they can't improve one aspect without hurting another one, not what you're describing. But I would say Go isn't on a Pareto frontier because the error handling is plain bad and could be fixed without any loss.by frollogaston
- > if you highly value language popularity; Go is not most popular
Go is similar to popular languages like C, JS/TS, & Python. And so, easy to get started.
> highly value a type system that catches errors
Probably these folks already use even less popular ML-style languages like OCaml & Haskell; or (comparatively) obscure ones like Agda, Idris, & rocq/Coq.
by ignoramous - Go is relatively easy to learn, and the semantics of the language make it more difficult to write "clever" code that's difficult to understand.
That's the main selling point, with a secondary point that it statically compiles so you don't have to do a whole Python/JS distribution thing for CLIs.
Java feels like the closest contender here, although it really sucks for CLIs due to start up times. I don't think it's the easiest to learn either, but I've never tried all that hard.
It only really makes sense to me at org-scale, though. I think you raise a very good point for individual projects, I too normally don't choose Go for that (unless I need compilation to make distribution to myself easier on corporate laptops).
by everforward - Something doesn’t need to be the best at anything to be on a Pareto frontier. And (usually) no one chooses on a single dimension; they choose a point in many that maximizes distance from zero, scaled by their preferences, if you are thinking of it like a frontier.by ratscylla
- Is there a language that you would argue is at least as good as Go at everything and better than Go in at least one thing? That would be the most straightforward way to argue against its Pareto optimality.
Listing particular sets of preferences for which Go is not optimal is not sufficient unless you can show the list to be exhaustive.
- Here's how my assessment selected Go (long before LLMs):
- I had to write a moderately complex program. I didn't want to do it in C, and I didn't want to learn Rust.
- So I spent roughly about 2 hours becoming familiar with Go and playing around in Go playground. I decided that this would work.
- And then I got started on my program and I was immediately productive and that software is still running today, along with all the other stuff I've written since then.
Programmer productivity is excellent with Go. And it has a thriving ecosystem. Of course, some things could be better, but I don't really have much issue with it's error handling or types.
by runjake - I like Go but a couple of these "advantages" wash out when you add the scale and typical usage patterns of agents.
| Go is Readable / Go is Maintainable
It's true that Go, as a low-magic language, tends to be very same-y looking across projects, which is incredible for being able to reliably understand your dependencies' source code. And its tooling is world-class. I love this about Go.
But in practice I've found that, working in a monorepo with multiple teams, contributors that don't have cross-team legibility as a priority will just write SO much more code. And with business logic, often the fact that I can read the code on a line-by-line level doesn't matter if I don't understand the wider context to know how something might effect spooky action at a distance.
Pre-agents, I witnessed a fast transition from a codebase that I could mostly hold in my head to one where large swathes of it had been written and rewritten until they were unrecognizable to me. Now we have agents and, since they are still mostly not good at software engineering in-the-large, the process of knowledge debt accumulation (and ofc tech debt accumulation) in a codebase accelerates tenfold without concerted effort in the other direction. Go being easy to read does not intrinsically help with that.
by dgunay - My problems reading code are understanding what the new vocabulary actually means, what it does in context, why it exists, etc. Doubly so when someone is pinging me to review a new 13000 line AI MR every 24h. Understanding an individual line because of some complex C++ feature, I don't remember it ever being an issue.
- My calculus is very simple these days:
If I care about performance, use Rust.
If I care about iteration speed, use TypeScript.
If I want a script or numerical code, use Python.
LLMs are better with Rust because the more expressive type system provides stronger guardrails especially when writing multithreaded code. Go is almost the worst conceivable design of a programming language for LLMs: powerful but weak guardrails. Only C and C++ would be worse.
LLMs don't struggle with the low-level lifetimes like humans do. They struggle with the high-level view because of limited context windows. That's why you want a powerful type system to enforce those global constraints. Go ain't it.
by zarzavat - You're not considering one of the important factors, token usage. Rust is a complex language and burns through tokens compared to Go. Python is good with tokens, but why would you use an interpreted language when you don't write the code. Same with TypeScript. Compile it.
I see language choice as only two now: Go or Rust.
Go for most systems, Rust for high performance.
by grantcarthew
I had the same convention until about a year ago when I started specifying Go for any kind of scripts on a whim.> If I want a script or numerical code, use Python.Now I get blazing fast, dependency-free static binaries with nearly equivalent OS/shell ergonomics as with bash or data processing with Python.
It’s a huge speed boost and being able to drop a binary on a new VM without messing with uv/pip is a breath of fresh air. LLMs hit zero road blocks doing 1:1 ports of existing Python/bash scripts.
by qlte- I disagree.
LLMs fail to produce bug free concurrent code even for very simple cases.
Golang lacks the ability to build descent abstractions, not even mentioning the wild west of additional tools and libraries needed for non trivial micro services.
For me it is a red flag, that LLMs allow people to produce more bad Golang code faster. This is only optimization for companies which can afford enough software developers to review the excessive amounts of code needed to solve trivial problems in Golang, which are builtin in every descent programming language and/or framework.
Use LMMs and use the right programming language. This might be Golang, but most probably it is C#, Java, Python, Ruby or even PHP. (Or Rust, C, D, ...)
by CopyOnWrite - Ask them to debug. LLMs are acceptable at writing code, but they're really good at spotting bugs in code that's already been written. What kind of results do you get if you tell them to look for bugs with a clean context subagent?
In my experience, LLMs are excellent at finding concurency bugs.
by a2ff6eeb0