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

531–540 of 586 posts

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

#531

Post by Jyaif »

geertj wrote: post #164

Let me share a hot take. I am deliberately taking this somewhat to the extreme, so please attack the idea not the person. Looking for thoughtful replies and good counterpoints, rather than language zeal. Let's assume that you need to write a program with a given set of requirements, and that you have a magic wand that can instantiate a high quality implementation of the program in any programming language instantaneo…

> The Rust implementation would be as efficient as possible on the given hardware with minimum memory/CPU

My sweet summer child.

And then there are the terrible compile times and huge binaries. In the scenario that you describe, what you want is Zig or C.

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

#532

Post by Ecko123 »

jeanbza wrote: 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…

[dead]

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

#533

Post by [deleted] »

thayne wrote: post #408
0x696C6961 wrote: post #401

Earlier quoted context omitted.

You're painting a picture where people writing Go are constantly drowning in nil pointer panics. This is not reality. You hit them occasionally and they're trivial to understand and fix.

nil pointer panics aren't nearly as bad as values getting zero initialized, then used in places that assume they were initialized, and getting subtle bugs because the state is inconsistent.

[deleted]

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

#534

Post by trimethylpurine »

the_sleaze_ wrote: post #495
trimethylpurine wrote: post #482

Earlier quoted context omitted.

Do you feel that this could equally apply to a Rust vs Go argument?

I do. Bike sheds do need to be painted after all, but its many less people who have the technical experience to know how many feet away from the property line it must be.

I had to think about that analogy for a moment. It's great. I wonder if that's how people feel when I use them and get a puzzled look.

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

#536

Post by osigurdson »

throwaway2037 wrote: post #369
osigurdson wrote: post #336

Earlier quoted context omitted.

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.

> far better than C# and Java's exceptions What is wrong with them? When writing enterprise CRUD apps, they are very useful.

If you reach a scenario that should crash your app, exceptions are fine. However, they are a pain (and brittle in the case of C#) when the intention is to handle them. This is the reason why many newer languages don't use exceptions.

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

#537

Post by osigurdson »

wannabe44 wrote: post #475
throwaway2037 wrote: post #369

Earlier quoted context omitted.

> far better than C# and Java's exceptions What is wrong with them? When writing enterprise CRUD apps, they are very useful.

People don't understand exceptional control flow. They think they have to catch them at every point, instead of using them as intended (having a central boundary of error handling where you have enough context whether to retry or abort the operation). So they think Go errors are better. With exceptions you can 1. Set exception breakpoints. 2. Have real stack traces. 3. No need to write 3 lines of boiler plate every 1…

There is a reason why Rust, Go and Zig don't have exceptions and it isn't because the language designers didn't understand them. While you can achieve the same thing using both approaches, errors as return values is generally simpler to reason about. Even in C# for example, exceptions are going to start taking a back seat with tagged unions which will be much better for expected failures.

I agree that Go's approach is a little cumbersome however. Suggest checking out Zig's approach which I personally think really nails it.

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

#538

Post by Cthulhu_ »

camkego wrote: post #212
rubiquity wrote: post #186

Earlier quoted context omitted.

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"

Why type out a prompt instead of link to an authoritative source? Gemini is not a source.

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

#539

Post by Cthulhu_ »

zero_shift wrote: post #118
jeanbza wrote: 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…

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…

I'd argue that this is neither down to the programming language nor LLM used, but down to your own company's requirements, testing, and code review practices - but you did point the latter out so you're aware of it. I think the only thing you realistically can try to do is slow down.

But it's also a trap I fall into myself - I don't usually thoroughly review my own merge requests because I wrote them, but now that LLMs generate them I don't review my code thoroughly either, and some issues have fallen through. Nothing critical, just stuff that, if someone asked me to review it, I'd flag up as something that could be polished a bit.

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

#540

Post by Pavilion2095 »

soniczentropy wrote: post #462
Pavilion2095 wrote: post #456

Earlier quoted context omitted.

And by that point a program written in go has been deployed and making money for months. These are two wildly different languages, people should stop comparing them as if they're targetting the same niche. Checks and protections that rust has aren't necessary in most cases, but increase development and maintenance time.

Do you have some evidence of that? I use both daily and my experience has been the opposite, if anything. Once I was as proficient at Rust as I was at Go, the "increased development and maintenance time" disappeared completely.

> Once I was as proficient at Rust as I was at Go

That's a big time investment for many people though. The one they—or rather their employers—cannot really afford.

Post reply on HN