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

561–570 of 586 posts

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

#561

Post by throwaway2037 »

wannabe44 wrote: post #475
throwaway2037 wrote: post #369

Earlier quoted context omitted.

> far better than C# and Java's exceptions What is wrong with them? When writing enterprise CRUD apps, they are very useful.

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…

This is a very good reply -- even if it largely agrees with me. I can say another thing as a person who has spent his career writing enterprise CRUD apps: Chained exceptions are a godsend for debugging failures in enterprise CRUD apps. Sure, the exception stack trace is some kind of Cthulhu-level abomination of 100+ lines, but you have a chance to diagnose the issue given the richness of the exception stack trace.

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

#562

Post by win311fwg »

osigurdson wrote: post #559
win311fwg wrote: post #555

Earlier quoted context omitted.

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

An exception is a data structure, usually comprised of a stack trace and some kind of related data, so that's true.

panic produces an exception, though, just like throw, raise, etc. as found in some other popular languages do.

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

#563

Post by 0x696C6961 »

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.

Again, it happens, but the impact is wildly overstated. I get so confused with people saying "once it compiles, it probably works" (regardless of language). The problems I struggle with need invariants that can't be expressed by any modern language features.

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

#564

Post by wfn »

win311fwg wrote: post #562
osigurdson wrote: post #559

Earlier quoted context omitted.

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

An exception is a data structure, usually comprised of a stack trace and some kind of related data, so that's true. panic produces an exception, though, just like throw, raise, etc. as found in some other popular languages do.

I'd strongly disagree, Go panic mechanism (but not just in the runtime sense but also in language feature sense) is quite distinct from what we typically understand "exceptions" to mean (which - esp. depending on language - are not at all just about handling programmer error). I think this is a decent article on exactly this: https://medium.com/@AlexanderObregon/why-go-panics-are-diffe...

But just imagine how exceptions typically have a whole propagation mechanism and type (=> catch) structure. Not so in Go. (Not implying some one model is better here, just flagging that panic vs exception are sufficiently distinct in meaningful (and deliberate) ways such that we can say they are "different", imho).

edit p.s. s/panic/panic+defer+recover p.p.s. On exception control flow - good comment upstream by 'wannabe44, imho: https://news.ycombinator.com/item?id=49270430

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

#565

Post by win311fwg »

wfn wrote: post #564
win311fwg wrote: post #562

Earlier quoted context omitted.

An exception is a data structure, usually comprised of a stack trace and some kind of related data, so that's true. panic produces an exception, though, just like throw, raise, etc. as found in some other popular languages do.

I'd strongly disagree, Go panic mechanism (but not just in the runtime sense but also in language feature sense) is quite distinct from what we typically understand "exceptions" to mean (which - esp. depending on language - are not at all just about handling programmer error). I think this is a decent article on exactly this: https://medium.com/@AlexanderObregon/why-go-panics-are-diffe... But just imagine how excepti…

> I think this is a decent article

Debatable. It correctly identifies that an exception is data structure (object), but claims that Go doesn't create one, even though it clearly does as it will plain print the contents of that "object" if you don't catch the exception. I will grant you that it doesn't pass the exception by value, which is different than in some other languages, but that's an implementation detail.

Furthermore it seems to claim that Go using basic stack unwinding precludes it from it having exception handlers, but that's an implementation detail too. Javascript also uses basic stack unwinding. Would you also say Javascript doesn't have exceptions or exception handlers?

Funnily enough, it is Javascript, not Go, that doesn't create the exception object automatically. You have to manually initialize the poorly named Error type manually (`new Error(...)`) in your code in order to create an exception. But that also is just an implementation detail.

> But just imagine how exceptions typically have a whole propagation mechanism and type (=> catch) structure.

What's typical? We do see some more advanced exception handling systems out there, but Javascript's is just as simple as Go's (in some cases even simpler), yet nobody that I have ever met claims that Javascript doesn't have exceptions/exception handlers. The one thing Javascript does have that Go doesn't is try/throw/catch syntax, but, of course, you can easily emulate that if you're really hung up on trivial appearances: https://go.dev/play/p/aXS5WEziLzS Exception handlers aren't defined by any particular syntax. That, again, is an implementation detail. Go does have syntax for exception handling even if its syntax is unique.

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

#566

Post by bb88 »

maleldil wrote: post #356
bb88 wrote: post #263

Earlier quoted context omitted.

C/C++ has "compiles but may have undefined behavior". Golang has numerous "compiles but has incorrect behavior" (normally known as footguns). Meanwhile with Rust, if you get past the compilation step, bugs become much much fewer. (You can still have memory leaks, but those are easily traceable). It seems like claude code can code Rust pretty well with Opus, and I've started moving codebases away from Golang to Rust a…

> You can still have memory leaks And deadlocks. "Fearless concurrency" helps a lot, but logic bugs are still possible.

Logic bugs in fairness happens in all languages. My unproven theory is that the fewer the foot guns, the better it will be for humans and LLMs to generate.

If Rust's footguns are limited to getting past the borrow checker, and memory links with their reference counted memory structures, I'm all for it.

Once I've fought the language once I typically won't have to fight it again. This is my problem with C++.

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

#568

Post by agonux »

cute_boi wrote: post #526
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…

Last week i implemented few program in Go and Rust, Fable wrote rust without any bugs, but go was full of concurrency bugs...

It seems like developers who champion Rust have a knack for making up a load of nonsense about other languages. Claude Fable knows exactly how to handle things in Go; the most recommended concurrency patterns are mastered by the likes of Sonnet, Opus, or Fable, and most of the concurrency "errors" cited in the Uber article are the sort of mistakes a Go beginner would make, some bugs are fixed on major go version too (capture loop..).

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

#569

Post by agonux »

odo1242 wrote: post #95
dralley wrote: post #23

Earlier quoted context omitted.

For whatever reason, maybe not even logical ones, Go repulses me. I don't know why exactly, I like the idea of Go, but the aesthetics rub me wrong. I think it's the use of pointers and "if err != nil {}" error handling spam. It reads as a highly compromised imitation of Python and C rather than a solid execution of some other idea. Rust is not the most beautiful language out there but it doesn't trigger any such reac…

For me it's mainly the if err != nil {} stuff and the fact that everything is package scoped (C-style enums and constants). You can pretty clearly see the limitations if you read, for example, the type of code the Protobuf compiler generates when trying to compile Protobuf/gRPC enums or structs into the way-more-limited Golang type system (this is despite the two being designed to work together). And it could really…

This is a classic pitfall. Every Go developer knows that using this assignment is discouraged, because interfaces are structures composed of two fields. You are assigning a pointer-type value to an interface. (_type = *bytes.Buffer, data = nil)

`out` is then no longer equal to `nil`.

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

#570

Post by agonux »

Dowwie wrote: post #104

Can anyone recommend a strong Go design/development agent skill?

https://github.com/samber/cc-skills-golang https://github.com/spf13/go-skills

I think , you can find a lot of skills for go.

Honestly , golangci-lint and you have already a lot of integrated tools with go to improve and modernize go code.

Post reply on HN