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

351–360 of 586 posts

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

#351

Post by badrequest »

ciupicri wrote: post #273
overfeed wrote: post #160

Earlier quoted context omitted.

>> ...there is no debate... > ...And so many languages have an opinionated formatter these days The crux of gp's post is for Go, there is no debate as 'go fmt' is the only one that matters. Black is great, but some people prefer Ruff, leading to ...debates about which formatter the team/org should use. Go's batteries-included philosophy makes those discussions moot on so many levels beyond formatting.

As if projects haven't used to have a coding style. What's so hard in saying that code should be formatted with Black, yapf, ruff etc, beats me.

Literally within this thread someone has already suggested using ruff instead of Black and nobody here are colleagues.

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

#352

Post by badrequest »

CoolestBeans wrote: post #332
dimgl wrote: post #307

Earlier quoted context omitted.

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.

Where does it say it isn't the easiest language to write? It says the exact opposite in the second paragraph.

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

#353

Post by pstuart »

xvedejas wrote: post #346
HAL3000 wrote: post #242

Earlier quoted context omitted.

> Go is bad so "I reach for Rust, Zig..." I hope my every competitor will take your advice to heart, as one of our competitors did when they read that "Go is not a memory safe language", so they wrote a blog about how they are porting to Rust. While our team was moving fast and using those "primitives that should almost never be used" around our long running production code base with success. Some time has passed and…

Where would one ever read that Go is not memory safe? That's just a false claim, and anyone believing it would have probably gone out of business regardless of choice of programming language.

My ex-boss was a JS guy and then moved over to Rust. He loathed Go because it has pointers and it's possible to use a nil pointer if you are not competent.

JS is fine for what and where it is, Rust is fine too. I just appreciate the stupid simple nature of Go and it does the job just fine.

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

#354

Post by keithnz »

joseda-hg wrote: post #102
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…

How would you compare it to C#? Stable-ish There's a lot of documentation and plenty of stablished patterns, so LLM can produce it no sweat Everything and the Kitchen Sink Performant, and safeish, even if not null safe

In my experience C# works out pretty good. I wrote a project in Go, it mostly went well, but it had weird bugs and the AI struggled to solve them. Rewriting in C# seemed a lot more robust. I use it a lot these days and I find the AI rarely has any issues with language/framework and you get pretty good results.

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

#355

Post by ameliaquining »

YuechenLi wrote: post #272
virtualritz wrote: post #187

Earlier quoted context omitted.

> Rust is comparatively worse, because LLMs don't make the same coding mistakes that humans do that justifies the existence of the borrow checker, [...] That's a pile of bollocks, pardon my French. Source/proof? And to the contrary: I've been working on a TS codebase that calls into C++ native/wasm-compiled code for six months now. The code is mostly LLM written. Over these last six months we had four use-after-free…

I'm curious on what you mean by "TS use-after-free", because as you obviously know, TS is GC'd. I don't have access to your codebase of course, but it seems to me that it is an FFI/native code boundary lifetime bug in the binding between TS and C++/WASM, not part of the TS managed memory. Comparing TS to native C++ FFI and/or manually managed WASM resources interface vs Rust + Rust ownership checked resources interfa…

Source? I haven't heard of that failure mode being especially prevalent. (Also, by "bypassing the borrow checker" do you mean unsafe raw pointers, Rc/RefCell, or something else?)

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

#356

Post by maleldil »

bb88 wrote: post #263
rubiquity wrote: post #195

Earlier quoted context omitted.

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

> You can still have memory leaks

And deadlocks. "Fearless concurrency" helps a lot, but logic bugs are still possible.

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

#357

Post by ameliaquining »

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.

Bun is an unrepresentative example of a Rust codebase for this purpose because (1) it was a direct port from a memory-unsafe language, and (2) it has a major C++ dependency (JavaScriptCore) whose objects in memory are deeply entangled with its own in very lifetime-complicated ways, which is something like the worst-case scenario for Rust's model of memory safety encapsulation.

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

#358

Post by iscoelho »

alfons_foobar wrote: post #276
fl0ki wrote: post #208

Earlier quoted context omitted.

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.

just curious, what problems do you see with gobgp? (I have only a rather basic familiarity with go, but was considering gobgp for an infra project...)

Not speaking to their code, but to start GoBGP has the worst performance of any BGP daemon by a large margin [1].

[1] https://elegantnetwork.github.io/posts/comparing-open-source...

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

#359

Post by maleldil »

overfeed wrote: post #160
zero_shift wrote: post #106

Earlier quoted context omitted.

I mean this isn't true, formatting is the most trivial part. And so many languages have an opinionated formatter these days (e.g. Black)

>> ...there is no debate... > ...And so many languages have an opinionated formatter these days The crux of gp's post is for Go, there is no debate as 'go fmt' is the only one that matters. Black is great, but some people prefer Ruff, leading to ...debates about which formatter the team/org should use. Go's batteries-included philosophy makes those discussions moot on so many levels beyond formatting.

Bad example. Ruff's formatter has the same style as Black. It's documented as a "drop-in replacement". The difference is mostly performance.

In any case, that's a single decision the project lead takes once.

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

#360

Post by maleldil »

frollogaston wrote: post #285
rsyring wrote: post #140

Earlier quoted context omitted.

But you're probably better off with Ruff these days: https://docs.astral.sh/ruff/ Similar to black but faster, written in Rust, by the same team who created uv.

This back-and-forth is a good example of why Go benefits from having a centralized linter. And uv isn't the official Python package manager even though it should be.

I don't get why this is a big issue. This isn't some recurrent decision to be made. It's something a lead decides once and the project follows. That's it. Many companies have style guides anyway (eg Google[1]); the choice of a formatter is much simpler.

[1] https://google.github.io/styleguide/go/

Post reply on HN