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

581–586 of 586 posts

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

#581

Post by cute_boi »

agonux wrote: post #568
cute_boi wrote: post #526

Earlier quoted context omitted.

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…

Your experience may vary, but Rust code once compile generally always works. I don't have same confidence about go or typescript. And, I don't know much rust, but I do use lot of go in my work.

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

#583

Post by larodi »

byward wrote: post #477
larodi wrote: post #464

Earlier quoted context omitted.

How about Swift and Erlang? Why are these always left out of comparisons?

Haven’t you heard? Swift is the first-ever corporate programming language, and we on HN can’t take its community efforts seriously to the extent of considering its potential value in general-purpose software. /s

I see it as a great language being driven (fw atm) by same buy who did Rust, no? And my take really is that the fact they were no good corpo created languages (GO is not one or what?), then it is totally fine to some big corpo like the much-disloved-yet-selling-shitloads-of-phones Apple to actually do something which benefits the world and does not incur costs ojn it.

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

#584

Post by wfn »

win311fwg wrote: post #565
wfn wrote: post #564

Earlier quoted context omitted.

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

Hey, I forgot to reply, but still wanted to quickly respond and to say - thank you for the detailed response, I concede your points are valid, and your perspective seems to be more accurate (with regards to incorporating nuance + reality fit) :)

> Javascript also uses basic stack unwinding. Would you also say Javascript doesn't have exceptions or exception handlers?

No, I wouldn't, so re: that - fair point;

For me, Go's error+panic lack of propagation + lack of exception type hierarchy are what stick out and seem vastly different to "typical"; and this does impact development, especially propagation mechanism / lack thereof. But I also haven't written lots of Go code, and could be possibly lacking experience, and am just looking from "typical" language lens (Java (not JS), Python, from my PoV)?

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

#586

Post by Myrmornis »

frollogaston wrote: post #428
Myrmornis wrote: post #329

> By enforcing a single, standardized format via the built-in gofmt tool I'd read about this many times before I started with Go so I was particularly disappointed to learn that it was a lie. The most important task of a code formatter is to break long lines; it doesn't do it. It doesn't even have an option to do it!

Because long lines aren't against the style guide for some reason.

The promise as I understood it was that it would map Go programs down to a unique format, as is done in Python or Rust. It's not required that the long lines violate style guides; we just want a unique blessed format.
Post reply on HN