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

551–560 of 586 posts

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

#551

Post by Cthulhu_ »

bushbaba wrote: post #344
joaohaas wrote: post #317

Earlier quoted context omitted.

Go design is not around being concise as possible, in fact it's the complete opposite. One of the cores behind Go is to make language simple, even if at the expense of more verbose code. Two main examples of this is the infamous 'if err != nil' and how you handle filter/map/funcional operations.

Yes but it’s err not error. The variable and method names are meant to be concise and highly readable without the CS fluff of Java naming hell.

Variable naming is a convention though, not a language feature.

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

#552

Post by Cthulhu_ »

maleldil wrote: post #362
joaohaas wrote: post #348

Earlier quoted context omitted.

I don't think naming convention is the kind of stuff that helps save tokens, specially considering how text is tokenized. On the other hand, being able to write 'list.filter(v => v.selected)' (or something similar) instead of: listFiltered := []Item{} for _, item := range list { if item.selected { listFiltered = append(listFiltered, item) } } would save much more tokens.

You can have that with generic functions, although Go's lambda syntax is too verbose. The slices package has DeleteFunc, which is kind of the opposite. I don't know why they have Filter. https://pkg.go.dev/slices#DeleteFunc

While Go has first-class functions and the like, functional programming is discouraged in Go; it's not optimized for it in either the language or the compiled result. It doesn't have tail call optimization for example, and naive functional coding may look "nice" (especially if it had for example arrow function syntax), but it won't have "mechanical sympathy". That is, no functional code (in Go) will be as fast as just iterating over a slice.

[0] has some good reasonings too, with history.

[0] https://www.reddit.com/r/golang/comments/c2a7b0/why_isnt_go_...]

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

#553

Post by cheikhcheikh »

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…

This has not been my experience at all with gpt sol on ultra/max. Some concurrent code is just really really hard to write and even in those cases LLMs can help, the barrier for extensive thorough testing and writing your own custom simulator, liveness and correctness tests is simply so much lower now.

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

#554

Post by [deleted] »

mac-mc wrote: post #319
wredcoll wrote: post #255

Earlier quoted context omitted.

Just reading the abstract, it talks about finding a number of bugs (across millions of lines of code) but I didn't see any claims that there would be fewer bugs in a different language. Go obviously does not stop you from writing buggy code. Neither does rust or zig or whatever. Does go make it more likely to have bugs? Or a specific class of bug? Like, the real world is about trade offs.

Uber has fairly large golang and java codebases so they have more of an apple to apples comparison here since they are both GC languages of a similar performance class. And if a large population tends to make more mistakes with 200hp sedan A vs 200hp sedan B, there is probably something up with the design of sedan A.

[deleted]

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

#555

Post by win311fwg »

osigurdson wrote: post #537
wannabe44 wrote: post #475

Earlier quoted context omitted.

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

> Go [...] don't have exceptions

What do you mean? Go has exceptions. Their use with errors is generally discouraged because exceptions, as the name literally implies, are technically designed for exceptional circumstances (programmer fault), not errors (environmental fault), but just like in every other language with exceptions you can do it, and even Go's own standard library uses exceptions for errors in some cases. The Go creators have even expressed openly that you should be pragmatic about it: use them for errors if it makes your code better. They are there to use.

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

#556

Post by win311fwg »

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.

I always wonder how those types of mistakes make it through your test suite. You'd need some kind of non-deterministic path to reaching the unintended zero value — but it would need to be a non-deterministic path that you wouldn't make deterministic during testing. I think we'd be curious to see what that code looks like.

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

#557

Post by aktau »

cookiengineer wrote: post #505
aktau wrote: post #497

Earlier quoted context omitted.

+1, I like to test in a similar way. For example if I'm making a CLI, the test will spawn the CLI for each test-case, instead of invoking the code directly. This provides a more realistic flow, and makes it clear which user journeys one is supporting. Faking responses I often do with environment variables, like: ts := httptest.NewServer(...) cmd := exec.Command(...) cmd.Env = append(os.Environ(), fmt.Sprintf("MYCLI_P…

I actually had to use a similar hack there due to the limitation that go test compilates cannot spawn themselves where I needed to have an environment variable with the actual binary prebuilt before the tests run. Took me a while to understand that TestMain doesn't cover that use case...

On Linux, "self" is /proc/self/exe. In general, I've seen people use `os.Args[0]`. But on checking again, I see there's even `os.Executable()` (https://pkg.go.dev/os#Executable) for this purpose.

I'm quite sure go test compilates can spawn themselves, I'm doing it on many platforms.

But, the test setup I was referring to was explicitly not that: the tests are spawning the main binary, not themselves. Using bazel+runfiles this is pretty easy to do. With the pure Go build tool, I'm not sure what approach I'd use to "guarantee" that I get a binary build for the same environment as the test.

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

#558

Post by [deleted] »

aktau wrote: post #557
cookiengineer wrote: post #505

Earlier quoted context omitted.

I actually had to use a similar hack there due to the limitation that go test compilates cannot spawn themselves where I needed to have an environment variable with the actual binary prebuilt before the tests run. Took me a while to understand that TestMain doesn't cover that use case...

On Linux, "self" is /proc/self/exe. In general, I've seen people use `os.Args[0]`. But on checking again, I see there's even `os.Executable()` ( https://pkg.go.dev/os#Executable ) for this purpose. I'm quite sure go test compilates can spawn themselves, I'm doing it on many platforms. But, the test setup I was referring to was explicitly not that: the tests are spawning the main binary, not themselves. Using bazel+ru…

[deleted]

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

#559

Post by osigurdson »

win311fwg wrote: post #555
osigurdson wrote: post #537

Earlier quoted context omitted.

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

> Go [...] don't have exceptions What do you mean? Go has exceptions. Their use with errors is generally discouraged because exceptions, as the name literally implies, are technically designed for exceptional circumstances (programmer fault), not errors (environmental fault), but just like in every other language with exceptions you can do it, and even Go's own standard library uses exceptions for errors in some case…

If you mean panic, it isn't really the same thing.

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

#560

Post by fl0ki »

alfons_foobar wrote: post #276
fl0ki wrote: post #208

Earlier quoted context omitted.

etcd is some of the most amateur code I've ever seen, despite being one of the oldest and presumably most mature "infrastructure" projects written in Go. goBGP is arguably even worse. I don't have a third place in mind that's even worth mentioning relative to these two.

just curious, what problems do you see with gobgp? (I have only a rather basic familiarity with go, but was considering gobgp for an infra project...)

Just look at the code. Anywhere you like. There's nothing I can say that will be a substitute for seeing it yourself.

I've had to use it as a library sometimes, and it's also really poorly designed as a library. There's no consistent principle for what is exported and what remains internal, so almost anything non-trivial you do may require you to copy-paste parts of the library code because something happened to not be exported. So you must think, okay sure, but in return for that you get a minimal and stable API. Nope! It also has some of the most API churn of any Go module, already up to /v4 and that's only counting the semver-major breakage they bothered to acknowledge, not the many semver papercuts along the way.

Post reply on HN