Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go is an ideal language for AI-assisted software engineering

developers.googleblog.com

Post reply on HN
Print view View original

201–210 of 586 posts

Re: Go is an ideal language for AI-assisted software engineering

#201

Post by jaynetics »

geertj wrote: post #164

Let me share a hot take. I am deliberately taking this somewhat to the extreme, so please attack the idea not the person. Looking for thoughtful replies and good counterpoints, rather than language zeal. Let's assume that you need to write a program with a given set of requirements, and that you have a magic wand that can instantiate a high quality implementation of the program in any programming language instantaneo…

I agree all in all.

I guess from a pure language POV, one might argue that rust leaves humans with more opportunity to add abstractions that are too clever and too hard to wrap your head around. That doesn't feel like a strong argument, though.

Then there is of course the ecosystem, where go maybe has better libraries for some stuff (while rust may have better ones for other things).

Re: Go is an ideal language for AI-assisted software engineering

#202

Post by triyambakam »

MeetingsBrowser wrote: post #191
rudedogg wrote: post #74

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…

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

https://avi.press/posts/2026-07-10-after-7-years-in-producti...

"After 7 years in production, Scarf has reluctantly moved away from Haskell"

And moved to Python, pretty much for the reasons you stated

Re: Go is an ideal language for AI-assisted software engineering

#203

Post by jm4 »

mg wrote: post #41

My expectation is that AI will give us a way to nicely quantify how productivity is impacted by choice of language. Because we can rerun the same request as often as we like and compare the results. And I expect that it will turn out Python is the most productive. As it is most easy to reason about. It allows for the most elegant expression of the idea behind a program. The first tests I have seen seem to confirm thi…

Purely anecdotal, but my experience has been that LLMs generate low quality python code. It's spaghetti code on par with what I've seen when companies I worked at tried offshoring development. It's basically what you get when you give bad or incomplete specs to a team of inexperienced programmers with poor development practices. It's usually good in small chunks, but it gets extremely sloppy as the scope of work increases and more decisions are introduced. Interestingly, I've seen LLMs generate good clojure code.

My guess is it comes down the the training data more than anything else, although I suspect functional languages will fare a little better. At least that's been my experience. There's undoubtedly a ton of python code in the training corpus and portions of it are of dubious quality. Niche functional languages likely have a smaller training corpus where a larger portion of it is better quality.

Re: Go is an ideal language for AI-assisted software engineering

#204

Post by Havoc »

This would have been more credible coming from someone other than the creator of the Go language.

I'm personally leaning into rust for LLM. The whole fussy compiler & errors surface at compile time seems IDEAL for LLMs for me. Hammering compile with tokens is a way better strategy than trying to deduce where stuff may fail at run time and try to catch it via tests.

Tokens are cheap, surprises at runtime are not. So a super anal compiler is what I want. I've looked at lean4 too as the logical next step but not confident I can guide an LLM competently enough for that.

Re: Go is an ideal language for AI-assisted software engineering

#205

Post by hugodan »

win311fwg wrote: post #132
hugodan wrote: post #91

Earlier quoted context omitted.

the Go runtime comes along for the ride when producing a wasm file, if you are interested in "minimal" (as in small or without extra cruft) then languages that do not require such a thing might be more adequate

Tinygo's base runtime is only around 10kb. It was minimal enough for my needs. gc's runtime would have been a non-starter for that task, to be fair, but Go isn't an implementation. It is, quite explicitly, a language. There are language implementations that would have been more minimal than that, sure, but there was no obvious way to get LLMs into alignment. I tried. Multiple times. When I switched to Go, it just wor…

If TinyGo works for your codebase, and those 10KB are something you can live with, then perfect.

Two things to keep in mind here:

1. TinyGo is not Go, more Go-like or adjacent

2. 10KB still matters a lot in a lot of minimal target/usage scenarios

Re: Go is an ideal language for AI-assisted software engineering

#206

Post by formerly_proven »

Thaxll wrote: post #139
rubiquity wrote: post #60

Earlier quoted context omitted.

Matches my experience as well. Go fans have conflated "can easily make something concurrent" with "does concurrency well." Go's primitives for concurrency should almost never be used directly and Engineers below a certain skill level shouldn't be allowed to use them directly ever for long running production code. As another example, Go still has not yielded a correct implementation of Raft or Paxos while there are do…

The "world" runs on Kubernetes which is using Raft: https://pkg.go.dev/go.etcd.io/etcd/raft/v3 Are you saying that this implementation is wrong? "This Raft library is stable and feature complete. As of 2016, it is the most widely used Raft library in production, serving tens of thousands clusters each day. It powers distributed systems such as etcd, Kubernetes, Docker Swarm, Cloud Foundry Diego, CockroachDB, TiDB, Pr…

Now there's three of them https://github.com/hashicorp/raft

Re: Go is an ideal language for AI-assisted software engineering

#207

Post by everforward »

Buttons840 wrote: post #55

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…

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

Re: Go is an ideal language for AI-assisted software engineering

#208

Post by fl0ki »

rubiquity wrote: post #186
Thaxll wrote: post #139

Earlier quoted context omitted.

The "world" runs on Kubernetes which is using Raft: https://pkg.go.dev/go.etcd.io/etcd/raft/v3 Are you saying that this implementation is wrong? "This Raft library is stable and feature complete. As of 2016, it is the most widely used Raft library in production, serving tens of thousands clusters each day. It powers distributed systems such as etcd, Kubernetes, Docker Swarm, Cloud Foundry Diego, CockroachDB, TiDB, Pr…

etcd has had numerous liveness and safety bugs, with one happening as recently as December of 2025. Would you consider that a correct implementation? You may be interested in knowing that the largest managed Kubernetes service in the world (AWS EKS) ripped out etcd for in favor of their homegrown consensus service for large scale EKS clusters: https://aws.amazon.com/blogs/containers/under-the-hood-amazo...

etcd is some of the most amateur code I've ever seen, despite being one of the oldest and presumably most mature "infrastructure" projects written in Go.

goBGP is arguably even worse.

I don't have a third place in mind that's even worth mentioning relative to these two.

Re: Go is an ideal language for AI-assisted software engineering

#209

Post by jerf »

rubiquity wrote: post #60
yosefk wrote: post #51

Earlier quoted context omitted.

Uber reported that their Go code has quantitatively more concurrency bugs than code in other languages, and while to me it seems obvious from looking at Go's concurrency model, this is backed by actual data. Is there any quantitative data to back the claim that Go is better in an LLM based workflow than another popular language?

Matches my experience as well. Go fans have conflated "can easily make something concurrent" with "does concurrency well." Go's primitives for concurrency should almost never be used directly and Engineers below a certain skill level shouldn't be allowed to use them directly ever for long running production code. As another example, Go still has not yielded a correct implementation of Raft or Paxos while there are do…

You seem to be implying, based on the rest of the thread, that Go has some sort of special defect that keeps it from implementing Raft correctly. But the "special defect" that Go has is that it in practice implements the same primitives in practice that almost every other mainstream language does, rather than implementing some sort of super-safe concurrency primitive like Erlang or Pony, or being immutable like Haskell. And even those things are of only marginal utility for Raft, preventing some local issues, but the hard part of Raft is more in the logic and the communication, for which none of these languages have any sort of special support or anything that will particularly help you get it right. Of the languages you listed only Rust provides any assistence over the standard mainstream languages, and like I said, in the context of Raft, it is not necessarily all that helpful.

If you want to see something that could potentially impact Raft's correctness, search the last couple of days of the HN front page for choreographic languages [1]. But none of these are even remotely mainstream enough to depend on for anything. Nor do I know if anyone in these languages has implemented Raft. A rather good test case for them, if any of them are looking. That's something that could actually help a Raft implementation's correctness, not just fiddle around the edges of local concurrency issues.

[1]: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Re: Go is an ideal language for AI-assisted software engineering

#210

Post by rbjorklin »

Imustaskforhelp wrote: post #54
mg wrote: post #41

My expectation is that AI will give us a way to nicely quantify how productivity is impacted by choice of language. Because we can rerun the same request as often as we like and compare the results. And I expect that it will turn out Python is the most productive. As it is most easy to reason about. It allows for the most elegant expression of the idea behind a program. The first tests I have seen seem to confirm thi…

It is unclear to me though how much of your expectation might be set by the training dataset. For example, Python and Typescript have the most amount of codebases and training being done on. So I feel as if that plays a part into the overall thing. Languages which are more niche have genuinely hard times (Try arturo lang for example), so it depends on a lot of things/nuance, or well that has been my experience trying…

Never tried Elixir myself but came here to say the same thing. Tencent put out this study showing that Elixir seems to reign supreme: https://autocodebench.github.io/
Post reply on HN