Live data from Hacker News

Go is an ideal language for AI-assisted software engineering

developers.googleblog.com

331–340 of 586 posts

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

#331

Earlier quoted context omitted.

Probably both, but I have to add: I agree with the post. I've done a ton of agentic development using Go over the past 6 months, and it hasn't let me down. You may ask "why not Rust, or Zig, or ____?" The reasons boil down to this: - There's a lot of Go code out there which the models have seen, so they know how to write it. - Go has an exceptional standard library, so you don't need to drag in 100 dependencies to cr…

SwiftUI has nothing to do with Swift… It’s just a UI framework that happens to have been written for Swift.

Fair—though SwiftUI has influenced/required new Swift features like Result Builders. I've found generating Swift to be a mixed bag. The LSP consistently reports stale errors which the model has to ignore, handling strict concurrency correctly can lead to ugly workarounds or huge refactors, the documentation for Apple's APIs aren't accessible to agents, the list goes on.

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

#332
post #307

I love the sleight of hand this blog post tries to pull off here. It doesn't matter than Go isn't fun to write because the AI is doing it now! Yeah so it sucked for the last twenty years? I know the main thesis is that Go is holistically good at software engineering so its weakness as a programming language is minimized. I've made a similar arguments that coding agents push the burden more into the other aspects of s…

I've never found that Go is not fun to write. On the contrary... Go is pretty refreshing with its simplicity. I found myself to be immensely productive writing Go.

For sure! Why is Google throwing their own language under the bus? They're literally saying in their article Go isn't the easiest language to write but that doesn't matter because its the best for maintaining a project. I also don't buy that readability and writeability are always being traded off.

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

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

It was and is a logical argument. Both C and Rust are much harder to learn.

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

#334
Google doesnt even use its own Go build system internally. Its all blaze / bazel, so they are not even taking advantage of the so called compiler feedback of Go. Also if languages are to be designed for agents not humans, its not clear whether the verbosity of Go will help agents at all

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

#336
post #27

Definitely agree with this article. At Netflix, I lead the Go language guild. We've been seen increasing reports of users finding their AI agents writing better Go code than other languages, and increasing reports of projects favouring Go over other languages. Two additional notes I'll add: - Go has _great_ resources on writing good Go code, including treasure troves at https://go.dev/doc/effective_go and https://goo…

If you know any other language, you basically already know Go (with the exception of the channels stuff). The biggest pain is the if err != nil stuff, which I know some people like but it is suboptimal in my view. While far better than C# and Java's exceptions, far worse than Zig's model.

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

#337

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…

Java has so many excellent concurrency containers, plus robust 3rd-party containers like JCTools. It puzzles me why Go communities do not offer such containers.

No thread/goroutine handles for fork/join handling from "outside", and no generics for many formative years that influenced tons of habits, then significantly weaker generics (improving very soon[1]), have all led to most concurrent code to be very "intrusive" - you create bare threads and add bare synchronization primitives (or nearly) by hand inside the threaded code to make it concurrent. `errgroup` is as far as a lot of code goes, in terms of sophistication.

Java leans heavily in the other direction: a lot of concurrency is added externally, without changing existing code, often in very declarative-flavored ways.

E.g. Future serves as a foundation for a ridiculous amount of stuff, while Go forces channels for `select` whether they model your problem nicely or not, and they're very difficult (often impossible) to wrap without changing semantics.

There are very obviously lots of counter-examples for both langs (`synchronized`, rill in Go, etc), and I expect Go to become more Java-flavored in time (it already has moved this direction somewhat, and 1.27 will enable a lot more). But I think it's a fair summary of broad ecosystem habits.

1: https://tip.golang.org/doc/go1.27 (not yet released)

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

#338
post #27

Definitely agree with this article. At Netflix, I lead the Go language guild. We've been seen increasing reports of users finding their AI agents writing better Go code than other languages, and increasing reports of projects favouring Go over other languages. Two additional notes I'll add: - Go has _great_ resources on writing good Go code, including treasure troves at https://go.dev/doc/effective_go and https://goo…

Which exact documents to you give them. The single style guide? The references as well? The additional detail listed in the guide as links? I'm curious to try your proposal, I just want more specifics.

I've made a pr to my agent trying to implement it. it did fine in blind a/b tests so just going to go forward

https://github.com/notque/vexjoy-agent/pull/908

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

#340
In my experience using Claude code for Go and Java code, I've seen little advantage for one language over the other in the LLM agentic context. I did a little experimentation with Zig which was less successful. Presumably to do with the relative lack of documentation and still being a somewhat moving target. That said, I have had Go concurrency code written with weaker models prove to be buggy, which shows up rapidly when reviewing with stronger models.
Post reply on HN