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

391–400 of 586 posts

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

#391

Post by overfeed »

the_sleaze_ wrote: post #372
badrequest wrote: post #351

Earlier quoted context omitted.

Literally within this thread someone has already suggested using ruff instead of Black and nobody here are colleagues.

It's a silly argument and the lowest form of bike-shedding on the level of tabs vs commas. People with no other substantive contributions use formatting as a beard. The first one to choose it (whatever it happens to be) wins and that's the end of it. If it isn't the end of it you've got a talent issue.

> It's a silly argument and the lowest form of bike-shedding on the level of tabs vs commas

Guess what other low-level bike-shedding argument 'go fmt' obviates? That's right - tabs vs spaces!

> If it isn't the end of it you've got a talent issue.

I know you meant this as a slur, but the implication is Go works better than other languages for those who have what you call "a talent issue"

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

#392

Post by baalimago »

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…

I've found that keeping very healthy test coverage solves issues like this. LLMs are very good at validating their own implementations with TDD.

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

#393

Post by cookiengineer »

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…

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?

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

#394

Post by cookiengineer »

baalimago wrote: post #392
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…

I've found that keeping very healthy test coverage solves issues like this. LLMs are very good at validating their own implementations with TDD.

With unit tests you gotta be careful though, oftentimes LLMs skip implementations with mockups that just say "not implemented yet" or similar and then the unit tests become pointless because they start to only test internal structures for being set / not default values.

For me it helped a lot to try to make containerized end-to-end tests and a custom TestMain for this, where I am using podman to run the integration tests. This way the end-to-end tests are forced to be on network level, and you can test protocol and API quirks much easier with LLMs.

Also, never forget to write a bootstrapping docs/ folder so that you don't have to re-explain these things all the time.

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

#395

Post by TheDong »

cookiengineer wrote: post #393
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…

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 criticism of the go type-system and language, and your comment doesn't hit on a valid solution.

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

#396

Post by aabdi »

za3faran wrote: post #324
aabdi wrote: post #280

Earlier quoted context omitted.

Uh compile time and linting efficiency, lightweight runtime, gc. There’s no equivalent competitor, it’s the best if u want to just write lots of undifferentiated code. To caveat this if u want to run about 50 agents or so in parallel, all the typescript projects burn ur disk via node modules. The rust ones take forever to compile and burn too much compute

Java and C# (JVM and .NET in general) are favorable here.

Uh at the very least Java is bad. the java programs we run take 4 gigs and burn my entire compute. Every1 used spring or guice and the di runtime, so tests are expensive for e2e with mocks. There’s no scrutable way I can run more than 2 or 3 on a standard laptop without burning out the thing.

Go can.

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

#397

Post by aryehof »

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…

One of the authors is a Google “Evangelist”. A “Chief” one to boot. Why would you expect different?

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

#398

Post by wltr »

hugodan wrote: post #101
wltr wrote: post #48

Earlier quoted context omitted.

Been doing bash scripting for years. Tried Go recently, on my, it’s so much better for everything OS scripting. I regret I haven’t started with Go years ago. All my scripts are rewritten to Go. I kept only a handful, those that are just a few lines and no logic.

I regret not going with bash or even sh when I had the chance. Nothing beats that for ubiquity and getting shit done. Go is behind, specifically, you have no guarantees that a given machine has Go installed, and doing stuff like gluing commands together, inspecting some files, pipe output around, or automate the boring thing in 30 seconds. Sure Go beats bash or sh when the thing you are doing starts to become real so…

That kept me away from the rewrite, but actually you can just throw a bin onto your server. At least for all my servers, I can do that. Migrating to Go helped me clean like hundreds of scripts into just a handful (tens) of slightly more complex, but unified programs with shared logic. I kept sticking to bash, not realising the complexity grew up already, and having a pile of simple scripts isn’t as simple as I thought. Go solved this beautifully, all the scripts were rewritten within just a month (with Claude assistance, but I’ve been checking on the code, it was OK), and now I can maintain them with less mental overhead.

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

#399

Post by anon7000 »

eudamoniac wrote: post #365
odo1242 wrote: post #156

Earlier quoted context omitted.

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…

Typescript is single threaded and 2-10x slower and does not compile into a binary.

Funny enough, the Typescript 7 compiler is no longer single threaded because it’s (ironically) now written in Go, not Typescript.

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

#400

Post by [deleted] »

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…

[deleted]
Post reply on HN