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

281–290 of 586 posts

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

#281

Post by skybrian »

radicalriddler wrote: post #157
skybrian wrote: post #21

Can't really argue with that, but In my experience, coding agents work quite well with TypeScript too. :)

The issue I always had with Typescript, was that LLM's like to find the easiest way to get a job done on a micro level (they seem to like to find the hardest design patterns to implement on the macro level tho, but language agnostic). What this means for Typescript, is unless you place guardrails everywhere, they'll cast their way out of a compiler problem with as any, or as unknown and then casting later. You either…

I haven't seen that too much, but I do have guardrails. I use Deno and run 'deno lint' as part of the build. It doesn't allow 'any'.

Also, I tend to ask planning questions, like "how would you implement this" and "what would the API changes be?" I'm picky about API's. Lately I've been using Deno workspaces (multi-package repos) and tell it when to make a new package or a new entrypoint. Maybe that helps?

If I just ask for features and don't look at the code, it will definitely make a mess, though. (A working mess, but it takes a while to refactor my way out.)

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

#282

Post by tracerbulletx »

Agreed, my media server is mostly AI written go at this point and it works great. Before AI the "one way to do something" was already my favorite feature of go, now it makes it much easier for me to use AI and still understand my own project.

https://github.com/SteveCastle/loki

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

#283

Post by redox99 »

radicalriddler wrote: post #157
skybrian wrote: post #21

Can't really argue with that, but In my experience, coding agents work quite well with TypeScript too. :)

The issue I always had with Typescript, was that LLM's like to find the easiest way to get a job done on a micro level (they seem to like to find the hardest design patterns to implement on the macro level tho, but language agnostic). What this means for Typescript, is unless you place guardrails everywhere, they'll cast their way out of a compiler problem with as any, or as unknown and then casting later. You either…

They're improving but you definitely need both a strong AGENTS.md and also usually many LLM passes (one for implementing a feature, another one for code quality, large passes every now and then for major refactors, etc).

That's not really a typescript thing though, just an LLM thing.

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

#284

Post by a2ff6eeb0 »

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…

Yeah, but AI is better at debugging than people are, so what's the issue?

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

#285

Post by frollogaston »

rsyring wrote: post #140
mholm wrote: post #127

Earlier quoted context omitted.

Black for Python https://github.com/psf/black

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.

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

#286

Post by AndyNemmity »

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…

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.

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

#287

Post by jopsen »

We're all biased here, me included.

IMO the concurrency model in go is the biggest reason, I'd hesitate to use it.

Managed memory, single threaded with lots of lints and good tooling. Is IMO what can raise my confidence in code, before I even review it.

Granted golang has a really good stdlib. Which counts for a lot.

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

#288

Post by amazingamazing »

odo1242 wrote: post #156
henrymerrilees wrote: post #133

Earlier quoted context omitted.

Is there a language that you would argue is at least as good as Go at everything and better than Go in at least one thing? That would be the most straightforward way to argue against its Pareto optimality. Listing particular sets of preferences for which Go is not optimal is not sufficient unless you can show the list to be exhaustive.

I'm not GP, but for me that would be TypeScript. TypeScript's tooling is as good as Go's across the board, it's very readable, it's a simple language, it has very few footguns, and it compiles fast. But it has better type safety than Go. This isn't an exhaustive proof as no language will every be fully Pareto optimal in practice (it's just not possible, there are too many dimensions), but I'd argue it's at least some…

Since when did does typescript compile faster than go? I do agree typescript is a good alternative but it is very different.

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

#289

Post by a2ff6eeb0 »

CoolestBeans wrote: post #75

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…

Are they wrong? If we're copy-pasting errors from applications into claude without looking at the errors (and, that is the future of generating code), why do you care about the language that's being used, outside of the LLMs being good at them?

I don't have serious metrics about if Go is better or worse than others, but LLMs seem to do fine with it.

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

#290

Post by a2ff6eeb0 »

CopyOnWrite wrote: post #168

I disagree. LLMs fail to produce bug free concurrent code even for very simple cases. Golang lacks the ability to build descent abstractions, not even mentioning the wild west of additional tools and libraries needed for non trivial micro services. For me it is a red flag, that LLMs allow people to produce more bad Golang code faster. This is only optimization for companies which can afford enough software developers…

Ask them to debug. LLMs are acceptable at writing code, but they're really good at spotting bugs in code that's already been written. What kind of results do you get if you tell them to look for bugs with a clean context subagent?

In my experience, LLMs are excellent at finding concurency bugs.

Post reply on HN