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

241–250 of 586 posts

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

#241

Post by rudedogg »

anthonypasq wrote: post #214
rudedogg wrote: post #74

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

I agree.

It would be neat to see a matrix of compile times vs. language features, showing things like:

- Bounds checks

- UAF prevention

- exhaustive enums

- test speed

But I think even among those the subtleties would make a fair comparison impossible.

Anyway I think this is all very nuanced, and anyone proclaiming language X is the language to use in 2026 lacks the experience/knowledge to consider these trade-offs and can safely be ignored.

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

#242

Post by HAL3000 »

rubiquity wrote: post #60
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?

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…

> 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 now their company does not exist anymore and we have a lot of their clients.

Thank you!

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

#243

Post by colwont »

OutOfHere wrote: post #235
jdw64 wrote: post #17

Earlier quoted context omitted.

Go doesn't have memory safety issues because of its GC, while Zig has UB problems. Zig might have slightly better performance, but I don't think choosing a language without memory safety is a good idea

What is UB?

undefined behaviour

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

#244

Post by super_flanker »

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?

Why would you think so? Rust provide better type system and abstraction mechanisms compared to Go, hence equivalent system should have less lines of code, at least in from my experience.

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

#245

Post by greenavocado »

vorticalbox wrote: post #29
greenavocado wrote: post #9

Earlier quoted context omitted.

Rust compiler is a tyrant. Type system is strict. Borrow checker is relentless. LLMs can't slop too much without being beaten up by the compiler.

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

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

#246

Post by _virtu »

Imustaskforhelp wrote: post #54
mg wrote: post #41

My expectation is that AI will give us a way to nicely quantify how productivity is impacted by choice of language. Because we can rerun the same request as often as we like and compare the results. And I expect that it will turn out Python is the most productive. As it is most easy to reason about. It allows for the most elegant expression of the idea behind a program. The first tests I have seen seem to confirm thi…

It is unclear to me though how much of your expectation might be set by the training dataset. For example, Python and Typescript have the most amount of codebases and training being done on. So I feel as if that plays a part into the overall thing. Languages which are more niche have genuinely hard times (Try arturo lang for example), so it depends on a lot of things/nuance, or well that has been my experience trying…

I've been in elixir for nigh a decade now and the one thing that you can try to pry from my cold dead hands is the BEAM. Elixir and Gleam are my go to languages right now and damn are they fun to write and reason in, but the part that has left me never wanting to leave the ecosystem is BEAM + OTP.

- BEAM makes monoliths sexy. You don't have to worry about a bunch of microservices, just focus on using proper process division for modeling your problem. - Debugging on the BEAM is first class. Drop into an interactive shell, pull up telemetry, or recon and hammer down on where your live app is slowing down if your metrics have a blindspot.

I could go on and on. I'm constantly blown away every day by the amount of time and effort and all of the sage learnings in distributed computing problems that came out of Ericsson that became the foundation of erlang + OTP + BEAM and in turn elixir + Gleam.

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

#247

Post by frollogaston »

radicalriddler wrote: post #83
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.

Agreed. Felt like a AEO / or GEO (generative engine optimization or whatever the field term is these days) puff piece. Seems too verbose for most people to bother reading.

Gemini overindexes on Reddit answers. It'll give me clearly wrong info just because one person on Reddit said it. People are probably already bot-spamming Reddit for this exact reason.

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

#248

Post by closeparen »

jeffbee wrote: post #197
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…

What primitives are we discussing? Any Go programmer can and should use the `go` keyword and the `sync.Mutex` type from their first program.

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.

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

#249

Post by super_flanker »

runjake wrote: post #68
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…

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…

> long before LLMs

I thought this thread was about an ideal language for LLMs, no?

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

#250

Post by icedchai »

super_flanker wrote: post #244
jeffbee wrote: post #193

Earlier quoted context omitted.

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

Why would you think so? Rust provide better type system and abstraction mechanisms compared to Go, hence equivalent system should have less lines of code, at least in from my experience.

Considering every other line of Go is `if err != nil`, this makes sense. I do prefer Go's simplicity, personally.
Post reply on HN