Go is an ideal language for AI-assisted software engineering • Hacker News Board

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

#161

Post by odo1242 » Tue, Aug 11, 2026, 7:21 PM UTC

ignoramous wrote: post #87

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…

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

Or Rust, Swift, etc.

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

#162

Post by jibal » Tue, Aug 11, 2026, 7:21 PM UTC

rubiquity wrote: post #151

jibal wrote: post #141

Earlier quoted context omitted.

I think you're projecting. You wrote > Go still has not yielded a correct implementation of Raft or Paxos while there are dozens in Java, C++, and Rust. That says that there are correct (i.e., bug-free) implementations in those languages. The GP noted > "we’ve found bugs in every Raft implementation we’ve tested, ..." which says that there aren't any correct ones. You then wrote > I didn't say other languages don't h…

The intersection of the set of Raft libraries Antithesis tested and all Raft libraries in existence do not fully overlap. I personally have worked on multiple proprietary ones that Antithesis would not have access to.

Even if so, the "You're misreading what I said" charge was bogus and it would be nice if you admitted that.

Edit:

> What are they implying by citing that? That Raft implementations in all languages have bugs?

That's what it says.

> I've already pointed out that is false.

You claimed that, and it's being disputed.

> Please let me know, since you're so comfortable speaking for them.

This has veered into bad faith ... I won't comment further.

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

#163

Post by foota » Tue, Aug 11, 2026, 7:22 PM UTC

YuechenLi wrote: post #145

foota wrote: post #107

Earlier quoted context omitted.

> "because LLMs don't make the same coding mistakes that humans do that justifies the existence of the borrow checker" Citation absolutely needed.

Sure, what I mean by that is that LLM makes different kind of mistakes than humans, they usually take the shortest direct route to accomplish their task. You can see that with the Bun Rust rewrite, I don't think any human coder would put as many `unsafe` and `Clone()` and `Arc ` in their code, so a lot of time, they would just attempt to bypass the borrow checker if they see it get in their way.

Ah, so it's more that "LLMs just bypass Rust's safety" rather than "LLMs write perfect C"? That's a more fair argument.

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

#164

Post by geertj » Tue, Aug 11, 2026, 7:23 PM UTC

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 instantaneously and for free. My hot take is that you would not want to choose Go, and you would likely want to choose Rust.

The Go implementation will have higher memory and CPU consumption due to garbage collection, while still being subject to memory bugs. The Rust implementation would be as efficient as possible on the given hardware with minimum memory/CPU, and it would be immune to memory bugs.

In my view, the biggest challenge with Rust, and where Go wins, is the relative difficulty of writing in Rust as the language is significantly more complex. With LLMs this is becoming a non-issue, and we are getting ever closer to having this magic wand (I'd argue that for smaller programs the wand already exists today). The article advocates that Go has excellent readability. I agree that Go has trivial syntax, but given that it's so verbose, I actually find it easier to read Rust code. Its higher expressivity allows you to see the higher level intention of a piece of code more easily.

Many of the other benefits the article mentions for Go are equally applicable to Rust: compiler error messages are super detailed and a great help to coding agents, auto-formatting, a great language server, and a package ecosystem.

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

#165

Post by aksss » Tue, Aug 11, 2026, 7:23 PM UTC

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…

That's not remotely what he's saying at all.

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

#166

Post by gnull » Tue, Aug 11, 2026, 7:24 PM UTC

cyanmoonx wrote: post #149

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?

Uber has a history of blaming the tool - in Facebook fashion - rather than admitting their “talent” sucks and they didn’t hire on merit. They used to blame Python a lot too - Python is slow compared to others but not so slow to matter that much, and you can build other services around it to handle certain work. Facebook - who chose PHP - used to blame iOS/Obj-c as the reason they couldn’t build a decent Facebook nati…

What concrete arguments are there to believe in your talent hypothesis instead of their tool hypothesis?

A couple more comments like this from you, and I'll be able to say, "cyanmoonx has a history of blaming the talent rather than bad tools". There being a history like that is neither an argument for nor against tools being bad. And also, don't forget that bad tools and bad talent don't rule each other out.

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

#167

Post by xavdid » Tue, Aug 11, 2026, 7:25 PM UTC

kstenerud wrote: post #7

The killer feature of golang for LLM dev is the tooling. forbidigo is what allows me to keep ambient config out of my app, and restrict file access to a small set of paths. The coverage tool has "nocover", so you can guarantee that every realistic path is exercised at least once ("100%" code coverage, which is not a marker for testing completeness, but rather for flagging code you forgot to test). Linting is really g…

> Linting is really good as well.

Maybe we are using different tools (or we've set it up wrong) but I'm consistently surprised at how slow Go's linting is (using golangci-lint). Takes nearly 5 minutes on our codebase after any change (which means I just don't run it locally or in-editor). It's remarkable how poor the experience is after using tools like Python's Ruff (instant) or Rust's Clippy. I'd have expected a fast, default setup that I could tune.

Event JS's Eslint, which runs in actual JS, takes 21 seconds for a full sweep (which I don't normally run, since the in-editor hints are so fast)

It's surprising, because so many of Go's dev tools are so well thought out!

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

#168

Post by CopyOnWrite » Tue, Aug 11, 2026, 7:26 PM UTC

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

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

#169

Post by 0x457 » Tue, Aug 11, 2026, 7:27 PM UTC

Yeah, no. Its good because LLM likes to copy paste things instead of doing code reuse which is the true go way of doing things. Imo, its hard to review Go code, probably why Go is yet to have a single correct Raft implementation.

I never seen k8s cluster that doesn't have some go process that segfaults once in a while because someone forgot to check `err`.

Only good thing got going for it is its vulnerability scanner. Which will be working overtime with all that "AI-assisted software engineering"

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

#170

Post by overfeed » Tue, Aug 11, 2026, 7:28 PM UTC

jibal wrote: post #162

rubiquity wrote: post #151

Earlier quoted context omitted.

The intersection of the set of Raft libraries Antithesis tested and all Raft libraries in existence do not fully overlap. I personally have worked on multiple proprietary ones that Antithesis would not have access to.

Even if so, the "You're misreading what I said" charge was bogus and it would be nice if you admitted that. Edit: > What are they implying by citing that? That Raft implementations in all languages have bugs? That's what it says. > I've already pointed out that is false. You claimed that, and it's being disputed. > Please let me know, since you're so comfortable speaking for them. This has veered into bad faith ... I…

Further, they can still edit their comment to correct it, but opting not to.