Live data from Hacker News

Go is an ideal language for AI-assisted software engineering

developers.googleblog.com

211–220 of 586 posts

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

#211
post #80

Earlier quoted context omitted.

So in terms of the mainstream languages, what would you say would be the most ideal language? (At least until Oct takes off!). Perhaps modern Java? .. Or even Zig?

For what purpose? Different use cases require different language features.

Fair enough but people build simple API's with DB interactions in a variety of languages, Go, C#, Java, Zig, Rust, etc.

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

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

Sorry to pile on, but yeah, I wanted to use etcd during 2021 and 2022, around v3.5, but etcd had serious issues including silent data corruption. If you are curious, ask gemini flash "there were a number of etcd releases years ago where it seems a new wave of developers came in and started breaking everything"

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

#213
post #68

Earlier quoted context omitted.

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…

> I didn't want to do it in C, and I didn't want to learn Rust. Sounds like you made a decision right there. The rest is just retro-justification, not a logical argument or comparative between options. It works for you, good.

Retro-justification is not some flaw it is most common way people choose tech stacks.

The only logic that matters most of time is business logic of solution serving problem statement and not logic of choosing a technical stack.

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

#214

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…

compilation time is massively important for developing with agents

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

#215
Go was designed as a systems language. They turned it into an applications language too, I'm guessing because turns out the greenthreading was uniquely good for that. But now it's awkward. The pointers and errors are not how you want an app lang to work. And LLMs struggle with error handling even more than humans.

Even as a systems lang, the error syntax is the worst part of Go. Can they at least put the ?/! syntax like in Rust instead of this "if err != nil" spam every other loc?

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

#217
post #162

Earlier quoted context omitted.

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…

But they are misreading what I said. My original post is clearly about Go. What they wrote is also ambiguous. > The antithesis author states: > "we’ve found bugs in every Raft implementation we’ve tested, including HashiCorp Raft, Aeron Cluster, OpenRaft, and MicroRaft" What are they implying by citing that? That every language has a Raft implementation with bugs? Yes that's probably accurate because lots of people m…

If we rely on their evidence alone, it suggests nobody has ever made a correct implementation, so we learn nothing about Go. "Go has yet to yield a correct one" is an extremely misleading way to present evidence that says the same thing about every language.

The only way this becomes useful for comparing languages is if somebody gives evidence of correct implementations in other languages. You're claiming they exist but with no evidence and suggesting they're secret. How do you know those don't have bugs? Did any concurrency bug experts do extensive testing on them? And can we disprove secret Go implementations of the same quality?

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

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

I'd like to know what you base your statement on that the Raft implementations in etcd or CockroachDB are incorrect. Your original paper does not mention those implementations, so where does that claim come from?

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

#219
post #162

Earlier quoted context omitted.

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…

But they are misreading what I said. My original post is clearly about Go. What they wrote is also ambiguous. > The antithesis author states: > "we’ve found bugs in every Raft implementation we’ve tested, including HashiCorp Raft, Aeron Cluster, OpenRaft, and MicroRaft" What are they implying by citing that? That every language has a Raft implementation with bugs? Yes that's probably accurate because lots of people m…

> That every language has a Raft implementation with bugs? Yes that's probably accurate because lots of people make Raft implementations for fun and learning. Again, Go does not have a single Raft/Paxos implementation that is rock solid. I have seen many in C++, Java, and Rust that are doing tens of millions of requests per second in production for over a decade.

No, they are citing that every Raft implementation that Antithesis has tested has bugs. The etcd implementation you note in go that has bugs also does tens of millions of QPS and is over a decade old. How are you confident that the proprietary implementations that presumably haven't been fully tested don't have subtle bugs that don't show up in practice?

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

#220
post #35

Earlier quoted context omitted.

"The only thing I haven't found is something to enforce error handling." errcheck, generally as manifested in golangci-lint, ensures you can't forget to do something with them. It would be odd for you to know about forbidigo but not errcheck as the former is much less widely known; is there something that errcheck doesn't do for you? It's worth pointing out that "discard this error on purpose" is a legitimate form of…

The rule I set for linting when an LLM is writing code is: Either you adhere to the rules, or you mark an exception with a valid reason. https://github.com/kstenerud/yoloai/blob/main/docs/contribut... Poor defaults break systems by a thousand cuts. They seem to make sense when designing the language (more convenient, less typing, etc), but then they very quickly become liabilities as project complexity increases. Go…

It isn't entirely clear to me how that relates to what I said. errcheck prevents you from dropping errors or catching them but then overwriting them before doing anything else. There's a flag you can twiddle to throw a lint error on using underscore to ignore an error, too, if you're really perturbed about that. I have a personal rule to always have a comment explaining why it's OK to do that that predates AI coding rules. This seems to meet your criteria.
Post reply on HN