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

251–260 of 586 posts

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

#251

Post by purplemoonx »

gnull wrote: post #166
cyanmoonx wrote: post #149

Earlier quoted context omitted.

Uber has a history of blaming the tool - in Facebook fashion - rather than admitting their “talent” sucks and they didn’t hire on merit. They used to blame Python a lot too - Python is slow compared to others but not so slow to matter that much, and you can build other services around it to handle certain work. Facebook - who chose PHP - used to blame iOS/Obj-c as the reason they couldn’t build a decent Facebook nati…

What concrete arguments are there to believe in your talent hypothesis instead of their tool hypothesis? A couple more comments like this from you, and I'll be able to say, "cyanmoonx has a history of blaming the talent rather than bad tools". There being a history like that is neither an argument for nor against tools being bad. And also, don't forget that bad tools and bad talent don't rule each other out.

[dead]

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

#252

Post by nasretdinov »

mrsilencedogood wrote: post #182
rubiquity wrote: post #60

Earlier quoted context omitted.

Matches my experience as well. Go fans have conflated "can easily make something concurrent" with "does concurrency well." Go's primitives for concurrency should almost never be used directly and Engineers below a certain skill level shouldn't be allowed to use them directly ever for long running production code. As another example, Go still has not yielded a correct implementation of Raft or Paxos while there are do…

To combine both TFA with this comment: I find that LLMs are ~fine at generating/editing gocode, or at least as ~fine as they generate most mainstream languages. But good god, the second it gets to anything concurrency-related, it just loses its mind. As much as it's gotten vaguely ok to try to let the agents loose on some bits of the codebase, they simply can't even do table stakes stuff with the kinds of concurrency…

Correct concurrent code is mind-bogglingly hard even for seasoned veteran humans (and don't get me started on distributed programming...), so it's hardly surprising that LLMs with their limited context windows into the code have a hard time writing correct concurrent code

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

#253

Post by [deleted] »

frollogaston wrote: post #240
win311fwg wrote: post #226

Earlier quoted context omitted.

> TinyGo is not Go Exactly. Go is a language. Tinygo is an implementation, like gccgo, gc, llgo, etc. Just as gcc, clang, and msvc are not C. > more Go-like or adjacent It is true that recover isn't fully spec complaint at this time. That's not entirely unusual for an implementation, though. msvc is famously not 100% spec complaint with C, but Microsoft still officially considers it a C compiler, as do most who use i…

"One of the things that most distinguishes Go is that it is not just a language, it’s a platform" according to the article

[deleted]

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

#254

Post by [deleted] »

igravious wrote: post #223
Havoc wrote: post #204

This would have been more credible coming from someone other than the creator of the Go language. I'm personally leaning into rust for LLM. The whole fussy compiler & errors surface at compile time seems IDEAL for LLMs for me. Hammering compile with tokens is a way better strategy than trying to deduce where stuff may fail at run time and try to catch it via tests. Tokens are cheap, surprises at runtime are not. So a…

fwiw I have a bunch of LLMs writing first Lean code and now Agda code. My observation. LLMs find reasoning about Agda as difficult as I find reasoning about C code. I've thrown a lot of gnarly C and Ruby code at all sorts of LLMs and they have only gotten more and more impressive as frontier models have gotten stronger. With Agda, they're like "hmm, tricky" whereas for me it's an impenetrable fortress. I've asked the…

[deleted]

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

#255

Post by wredcoll »

nperez19 wrote: post #158
amazingamazing wrote: post #97

Earlier quoted context omitted.

Link to the uber report? Could not find it (unless it is this: https://www.uber.com/us/en/blog/data-race-patterns-in-go/ )

This is the actual link to the academic paper ( https://arxiv.org/pdf/2204.00764 )

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.

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

#256

Post by jeffbee »

closeparen wrote: post #248
jeffbee wrote: post #197

Earlier quoted context omitted.

What primitives are we discussing? Any Go programmer can and should use the `go` keyword and the `sync.Mutex` type from their first program.

It's pretty easy to get yourself into trouble with channels: deadlocks, send on closed, channel leaks, deadlocks "fixed" thoughtlessly with arbitrarily-sized buffers, etc.

This seems to have little to do with Go's facilities. Any concurrent program has hazards like these.

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

#257

Post by jay_kyburz »

geertj wrote: post #164

Let me share a hot take. I am deliberately taking this somewhat to the extreme, so please attack the idea not the person. Looking for thoughtful replies and good counterpoints, rather than language zeal. Let's assume that you need to write a program with a given set of requirements, and that you have a magic wand that can instantiate a high quality implementation of the program in any programming language instantaneo…

If you are going to take the human out of the loop you could just write the program in assembly or machine code directly.

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

#259

Post by mbreese »

jdw64 wrote: post #34
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…

I have a question: why do you think Go is better compared to other languages? After all, learning a new language takes a lot of time. While basic syntax is common and quick to pick up, mastering a language's specific mental model requires a significant time investment, which is why I've used Go before but never seriously. My interest was piqued recently when I heard about TypeScript tooling being ported to Go, and I…

Go is really amenable to being used to write code by LLMs. New code takes time to pick up, but the LLM is a quick study.

In my opinion, it has little to do with the speed of the language. The large quantity of source code to train on is quite helpful, but I think it's something else.

There are three things that I think make it well suited to LLM authorship -

1) static typing and a quick compiler - a variable can't change type after it's declared (unlike Python) makes Go more robust compared to dynamic languages. You (almost) always know what the type of a variable is. And the quick compiling with hard-stop errors means that the LLM gets a solid signal for each round.

2) It's quite opinionated, syntactically. There is generally one way that Go lang code is supposed to look. That means it's pretty easy to read as well as write. The lack of things like operator/method overloading make it an easy language to reason about.

3) the stdlib and limited dependencies. Dependency trees tend to be shallow, and because of the static linking (by default), you can generally be confident that what you wrote will run.

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

#260

Post by zrg »

I've written go most of my career. I've "written" tonnes of AI assisted go. Since February however all my new software projects and production services have been written in rust. I never even wrote rust before December. I've barely even looked at any of the source code, I find i just trust the AI to write rust way more.

But perhaps that's also a side effect of maybe having prior opinions about go and the number of foot guns I've let off

Post reply on HN