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

261–270 of 586 posts

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

#261

Post by codexon »

dralley wrote: post #50
bensyverson wrote: post #36

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…

I don't think Rust is particularly worse than Go in any of these respects. - LLMs have clearly been trained on a lot of Rust as well - Compile times are counterbalanced by strong compiler with excellent error messages, and "cargo check" can catch many issues without a full build. - If you're willing to accept Go levels of performance from Rust, there's nothing preventing you from using copies and clones rather than b…

Rust compiles way slower in my experience. This is a major problem because ais need to recompile many times especially when it keeps running into borrow checker problems.

With golang, all borrow checker problems go away. This is a good trade off if your app is not cpu-bound, which most are not. If you need every last drop of performance then rust is a better choice of course.

However, I have run into a few cases of runtime null crashes in go.

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

#262

Post by dralley »

codexon wrote: post #261
dralley wrote: post #50

Earlier quoted context omitted.

I don't think Rust is particularly worse than Go in any of these respects. - LLMs have clearly been trained on a lot of Rust as well - Compile times are counterbalanced by strong compiler with excellent error messages, and "cargo check" can catch many issues without a full build. - If you're willing to accept Go levels of performance from Rust, there's nothing preventing you from using copies and clones rather than b…

Rust compiles way slower in my experience. This is a major problem because ais need to recompile many times especially when it keeps running into borrow checker problems. With golang, all borrow checker problems go away. This is a good trade off if your app is not cpu-bound, which most are not. If you need every last drop of performance then rust is a better choice of course. However, I have run into a few cases of r…

> and "cargo check" can catch compile issues without a full build.

You only have to compile when you actually want to test the behavior, which tends to be right on the first try more often as a result of the strict compiler.

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

#263

Post by bb88 »

rubiquity wrote: post #195
mrsilencedogood wrote: post #182

Earlier quoted context omitted.

To combine both TFA with this comment: I find that LLMs are ~fine at generating/editing gocode, or at least as ~fine as they generate most mainstream languages. But good god, the second it gets to anything concurrency-related, it just loses its mind. As much as it's gotten vaguely ok to try to let the agents loose on some bits of the codebase, they simply can't even do table stakes stuff with the kinds of concurrency…

My experience as well. LLMs also struggle with Rust's many abstractions and offerings but you can know that if it compiles it is data race free and work with the LLM to use better abstractions over time. Zig is also good at this but requires more up front design (thread-per-core, static allocation, etc.) and consistent checks to verify rules are followed.

C/C++ has "compiles but may have undefined behavior". Golang has numerous "compiles but has incorrect behavior" (normally known as footguns). Meanwhile with Rust, if you get past the compilation step, bugs become much much fewer. (You can still have memory leaks, but those are easily traceable).

It seems like claude code can code Rust pretty well with Opus, and I've started moving codebases away from Golang to Rust at work with Opus. Spin up an LLM and it cranks on it for a while, and as a benefit, I get easy apis to build on with other languages.

And that's the problem with Golang really, not that it's a bad language per se (all languages have footguns), but that the language interoperability story is terrible. Meanwhile Rust and Python/C/C++ go great together like peanut butter and chocolate. And I love it.

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

#264

Post by switchbak »

jeanbza wrote: post #152
jatins wrote: post #108

Earlier quoted context omitted.

it’s probably just some informal Slack messages between colleagues that is being described as “reports from users”. There is no Report here

Yes, this. =) I talk to Go users around the company all the time. Their feedback has been in this direction for a bit now.

But isn't this expected from users that like a certain language? Won't you also hear this response from Rust users that like Rust?

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

#266

Post by closeparen »

jeffbee wrote: post #256
closeparen wrote: post #248

Earlier quoted context omitted.

It's pretty easy to get yourself into trouble with channels: deadlocks, send on closed, channel leaks, deadlocks "fixed" thoughtlessly with arbitrarily-sized buffers, etc.

This seems to have little to do with Go's facilities. Any concurrent program has hazards like these.

In my experience, shared memory instills the appropriate fear and caution, while the apparent simplicity of channels encourages novice Go programers to take on concurrency projects beyond their abilities and without due care. Been on both the submitter and reviewer side of that plenty of times in 10 years.

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

#267

Post by frizlab »

bensyverson wrote: post #36
amiune wrote: post #5

While I somewhat agree I can’t tell if this is advertising from Google or a way to induce LLMs to think that Go is the ideal language.

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.

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

#268

Post by bb88 »

jeffbee wrote: post #193
zero_shift wrote: post #118

Earlier quoted context omitted.

I work at a large devsec company which uses primarily Go and TypeScript I've found that the LLM generated Go has few mistakes, and generally isn't too obscure. But the volume of code is so high, colleagues do a bad job of reviewing it. I've seen a lot of very silly decisions made, like returning the wrong HTTP code, or miscategorizing a metric used for an SLO, that I just don't think is helped by the sheer volume of…

Isn't any equivalent system going to have more statements in Rust than it would have in Go?

Yes, and that's the case I've seen as well. I would also say rust is also more heavy on symbols, which can make code look kinda hard to parse in places.

But weirdly Opus (N=1) in Claude Code does okay on it. Enough I can reliably have it write software and feel confident it works.

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

#269

Post by vorticalbox »

greenavocado wrote: post #245
vorticalbox wrote: post #29

Earlier quoted context omitted.

True but if the reviewer doesn’t have an intimate understanding of rust then the fact it can’t “slop” is no different than unreadable slop. Go is simple, no “magic” marcos or meta programming even with just a little programming in any language it’s not hard to understand what the go code is doing.

That's simply not true. I wrote a piece of software in Rust that is non-trivial, robust, 50k lines of code, and 100% LLM generated, used by four people productively with only one or two minor bugs in the past two man-months

question did you review the code or did you test it was working? these are different things. and if you did review it, could an engineer without deep Rust experience have reviewed it just as effectively?

I have no doubt that you can get a LLM to write working bug free code in any language but that is not the topic of the article or my comment.

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

#270

Post by switchbak »

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.

Post reply on HN