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

401–410 of 586 posts

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

#401

Post by 0x696C6961 »

TheDong wrote: post #395
cookiengineer wrote: post #393

Earlier quoted context omitted.

So your problem is the default/zero values of properties? In Go the convention is kind of to have a constructor pattern with a NewStruct(...) *Struct method that initializes all properties. Also can't you build your own validator for that with the reflect package in the Add() method of your UI graph to prevent this sorta thing?

The Go std library, as well as practically all go library code, is full of things that don't fully initialize all properties and things that nil-pointer-panic if you hold them wrong, so no, no matter what you do you have to deal with this wart of Go. The go type-system is simply incapable of enforcing nil-safety without being no longer able to compile the go stdlib nor most code in the wild, so it's a quite valid cri…

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.

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

#402

Post by jchook »

beaker52 wrote: post #386

It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making. What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go. Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squint…

Good point.

It's sometimes challenging to get a Rust program to compile... but if you do, it's probably going to work.

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

#403

Post by socketcluster »

Plain JavaScript is the ideal language for AI coding. It's very good with complex architectures.

I think partly it's because the training set contains a lot of JS, but also because complex software written in JavaScript must have impeccable architecture in order to exist at all.

It's rare to encounter a complex, functioning JavaScript application with bad architecture. I've never met any engineer smart enough to maintain a large spaghetti-code JavaScript project.

On the other hand, I've seen horrible TypeScript projects. If it wasn't for the helpful type annotations, no human being would have been able to maintain it.

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

#404

Post by anon7000 »

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…

As someone who’s written huge amounts of Typescript, and no Go… the JS/TS ecosystem is absolutely atrocious. I’ve worked on developer productivity teams for almost a decade and JS tooling issues are a never ending battle. Every upgrade to major dependencies almost anywhere in your stack will 1. Include breaking changes and required migrations, and 2. Will also force you to update other dependencies for compatibility, which may have their own breaking changes and so on and so forth.

The tooling will let you do whatever you want, but the lack of standardization is very poor. Even now, many are switching from Eslint to Oxlint. Or Jest to Vitest. Or tsc to faster build tools. There is massive fragmentation.

I frankly yearn for a language that is always backwards compatible (JS itself might be, but ESM/CJS/etc. won’t be because the language relied on 3rd party/runtime-provided methods of importing modules for so long…), and actually has standard basic tooling from the start. Along with halfway decent security posture towards dependencies. And no need to manage a runtime. And produces smaller images.

Like if it’s just about the language, sure TS is extremely usable, async is extremely easy because it’s not a real thread, etc etc. But has plenty of quirks due to being tacked on top of JavaScript. (For example, being forced to import typescript from “.js” extension and not “.ts” with certain normal compiler settings…)

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

#405

Post by laszlojamf »

I use go for work and basically 100% agent-driven. I'd say using go with agents is a lot better than without. We use to have a consistent source of production errors where we forgot the pointer case in type switches (we'd pass a pointer to a struct where a concrete struct was expected and vice versa). AI hasn't made that mistake once in my experience.

That being said, the whole thing about go being "readable" is a little bit of a two-edged sword. Sure, it's straight-forward to read, but it's pretty verbose. And agents are good at producing a lot of text. The problem with reviewing go code for me is to see the forest for the trees. Subtle misunderstandings often hide in the vast amount of code that you have to read through while keeping the whole context in your head.

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

#406

Post by kromem »

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…

Yep. Have a primarily Go backend and from even early on the agents were doing a good job.

Now they are even better than me.

I do think the way software is organized for primarily agent driven repos will need to change a bit from how I preferred setting things up. (Guessing we're going to be returning to a world of microservices in the near future.)

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

#407

Post by steve1977 »

jryle70 wrote: post #265
tpoacher wrote: post #79

"Oreo cookies are the tastiest cookies currently in the market!" ~ Oreo cookie company.

Isn't that true? Prove them wrong. (Someone who doesn't even eat cookie but heard a lot of praise of Oreo)

Oreo is mostly praised in the USA. Which says more about the USA than it says about Oreos.

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

#408

Post by thayne »

0x696C6961 wrote: post #401
TheDong wrote: post #395

Earlier quoted context omitted.

The Go std library, as well as practically all go library code, is full of things that don't fully initialize all properties and things that nil-pointer-panic if you hold them wrong, so no, no matter what you do you have to deal with this wart of Go. The go type-system is simply incapable of enforcing nil-safety without being no longer able to compile the go stdlib nor most code in the wild, so it's a quite valid cri…

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.

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

#409

Post by a2ff6eeb0 »

treyd wrote: post #380
a2ff6eeb0 wrote: post #290

Earlier quoted context omitted.

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.

Debugging concurrency issues isn't a syntactic process so they have to resort to println debugging. This works but isn't exhaustive and burns a lot of tokens.

They do a fantastic job just by inspecting the source. It's obviously not exhaustive, but it's quite good.

Test it on your last concurrency bug. Point fable at the rough symptoms and ask to find where the issue is by inspection. It'll probably do just fine.

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

#410

Post by Someone »

jibal wrote: post #141
rubiquity wrote: post #85

Earlier quoted context omitted.

You're misreading what I said. I didn't say other languages don't have buggy Raft/Paxos implementations, just that Go is yet to yield a single correct one.

I think you're projecting. You wrote > Go still has not yielded a correct implementation of Raft or Paxos while there are dozens in Java, C++, and Rust. That says that there are correct (i.e., bug-free) implementations in those languages. The GP noted > "we’ve found bugs in every Raft implementation we’ve tested, ..." which says that there aren't any correct ones. You then wrote > I didn't say other languages don't h…

> The GP noted

>> "we’ve found bugs in every Raft implementation we’ve tested, ..."

> which says that there aren't any correct ones

That only follows if the GP tested every Raft implementation in existence and no new ones were written since.

Post reply on HN