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

231–240 of 586 posts

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

#231

Post by afdbcreid »

virtualritz wrote: post #187
YuechenLi wrote: post #76

I wouldn't say Go is IDEAL for AI coding, but it certainly has the case for one of the best programming languages that currently AI uses. Go definitely has its share of problems for human authors because it's so verbose and boilerplate heavy, which means it's less of an issue with LLMs than it is for human coders. Rust is comparatively worse, because LLMs don't make the same coding mistakes that humans do that justif…

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

The problem with ownership tracking is that it's global. Humans are bad with global things, linters too, but LLMs are exceptionally bad at them due to the context window and (currently, at least) not knowing enough where to search. So yes I'd expect them to make the same mistakes as human and even more frequently.

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

#232

Post by gr_norm »

triyambakam wrote: post #202
MeetingsBrowser wrote: post #191

Earlier quoted context omitted.

> leveraging their compilers and enforcing more correctness guarantees. The counter argument here is that these checks cause slower compile times and were designed to prevent common mistakes humans make. If models get good, they may not need the same checks human written code needs. For example, frontier models already will virtually never produce a typo. Humans need time to think, but a model’s bottleneck is in how…

https://avi.press/posts/2026-07-10-after-7-years-in-producti... "After 7 years in production, Scarf has reluctantly moved away from Haskell" And moved to Python, pretty much for the reasons you stated

This is a rather poorly-written post that more or less boils down to "GHC isn't fast enough to let us make deep-reaching changes to our codebase all the time" (fair, but this shouldn't be necessary if your abstractions are solid? seems to telegraph very substandard engineering practices, but I guess that's what you get with vibecoding) and vague complaining about how the Haskell community isn't all-in on AI.

I was curious about this so I dug further, and by the author's own admission, they've only made the switch for basic CRUD logic without performance needs, not their core services: https://news.ycombinator.com/item?id=48865986.

It's also pretty unsurprising, given what we know about LLMs' style transfer abilities, that transferring parts of an existing Haskell codebase into Python would avoid a lot of the errors and pitfalls that codebases originating in Python are known for. From my experience writing lots of Python, this does not continue to hold true as you let the agents loose on your Python codebase.

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

#233

Post by frollogaston »

hugodan wrote: post #30

Who cares? Languages are tools, LLMs are tools. Use the ones more appropriate for what you are trying to do. Is Go better than CSS if you are doing web layouts? Is it better than zig if you are outputting minimal wasm deliverables? Is it better than swift if you are doing iOS specific development? Is it better than bash for OS scripting? Think about what you are doing and choose appropriately. This was true before LL…

The article is about which tool is more appropriate, and you're dodging that question. Every use case has multiple langs you could use for it, and there's no universally agreed-upon choice. Like if you're writing a typical web API backend with LLM assistance from scratch, which do you use between JS, Py, Java, Go, Rust, etc?

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

#234

Post by colwont »

yosefk wrote: post #51
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…

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?

yup, show receipts

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

#235

Post by OutOfHere »

jdw64 wrote: post #17
jhawk28 wrote: post #10

Earlier quoted context omitted.

Zig seems to have more closely aligned with what Go devs prefer.

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?

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

#236

Post by Dylan16807 »

pmarreck wrote: post #121
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)

what is "Black"? (For hopefully obvious reasons, I couldn't find results with google, lol)

What did you search?

If I do the simplest possible thing that isn't a single word, by highlighting "opinionated formatter these days (e.g. Black)" and clicking search, I get the right result. I also get the right result for black formatter, and I get the right result if I yolo the entire comment as my search.

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

#239

Post by colwont »

gr_norm wrote: post #113
YuechenLi wrote: post #76

I wouldn't say Go is IDEAL for AI coding, but it certainly has the case for one of the best programming languages that currently AI uses. Go definitely has its share of problems for human authors because it's so verbose and boilerplate heavy, which means it's less of an issue with LLMs than it is for human coders. Rust is comparatively worse, because LLMs don't make the same coding mistakes that humans do that justif…

> Rust is comparatively worse, because LLMs don't make the same coding mistakes that humans do that justifies the existence of the borrow checker, it only seems to get in their way, and they spend more time fighting Rust's infrastructure than writing code. I have found exactly the opposite to be true: as always, people think they can write safe concurrent code without the machine checking them and end up getting it c…

Was also going to say this. If anything, the borrow checker in Rust is more likely to save you from LLM issues, because it won't bloody compile.

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

#240

Post by frollogaston »

win311fwg wrote: post #226
hugodan wrote: post #205

Earlier quoted context omitted.

If TinyGo works for your codebase, and those 10KB are something you can live with, then perfect. Two things to keep in mind here: 1. TinyGo is not Go, more Go-like or adjacent 2. 10KB still matters a lot in a lot of minimal target/usage scenarios

> TinyGo is not Go Exactly. Go is a language. Tinygo is an implementation, like gccgo, gc, llgo, etc. Just as gcc, clang, and msvc are not C. > more Go-like or adjacent It is true that recover isn't fully spec complaint at this time. That's not entirely unusual for an implementation, though. msvc is famously not 100% spec complaint with C, but Microsoft still officially considers it a C compiler, as do most who use i…

"One of the things that most distinguishes Go is that it is not just a language, it’s a platform" according to the article
Post reply on HN