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

521–530 of 586 posts

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

#521

Post by greenavocado »

vorticalbox wrote: post #269
greenavocado wrote: post #245

Earlier quoted context omitted.

That's simply not true. I wrote a piece of software in Rust that is non-trivial, robust, 50k lines of code, and 100% LLM generated, used by four people productively with only one or two minor bugs in the past two man-months

question did you review the code or did you test it was working? these are different things. and if you did review it, could an engineer without deep Rust experience have reviewed it just as effectively? I have no doubt that you can get a LLM to write working bug free code in any language but that is not the topic of the article or my comment.

Probably at 50x the cost LOL

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

#522

Post by za3faran »

dnautics wrote: post #468
Cthulhu_ wrote: post #459

Earlier quoted context omitted.

Fair criticism, it's my main gripe with Go as well - it's not strict enough when it comes to e.g. nil, enums, and type safety. Annotations are supported but they're just strings. Projects require additional tooling / linters to check for things like unchecked errors and many more "gotchas" that I think could (should?) be part of the compiler or standard tools. Trivial example, Go's compiler will error when you have a…

i never run into these issues in >100k loc of productionized llm generated elixir (nil safety, type issues). i wonder, is there something architecturally in go that makes this a particular problem?

Up until quite recently, golang lacked generics, so `interface{}` was passed everywhere. It does not have typesafe enums (you can pass integers and it will compile). It has no way of declaring immutable structures. It does not have pattern matching.

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

#523

Post by za3faran »

aabdi wrote: post #499
KptMarchewa wrote: post #457

Earlier quoted context omitted.

You don't have to use Spring or the typical enterprise IOC that plagued 00s and 10s Java.

I mean yes true but no one would justify migrating the code it’d be so expensive. Dagger was very nice for the newer services and the ones that used straight rx were like less hell

You might want to check out Quarkus, Mirconaut, or Helidon MP. They do build time DI, and are more focused on performance and reduced resource usage. They are similar enough to Spring, and I believe Quarkus and Micronaut have an optional Spring compatibility layer that one can use. LLMs could help with migration if the codebase is well written.

You might also want to checkout Project Leyden[1]

https://openjdk.org/projects/leyden/

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

#524

Post by codexon »

dralley wrote: post #262
codexon wrote: post #261

Earlier quoted context omitted.

Rust compiles way slower in my experience. This is a major problem because ais need to recompile many times especially when it keeps running into borrow checker problems. With golang, all borrow checker problems go away. This is a good trade off if your app is not cpu-bound, which most are not. If you need every last drop of performance then rust is a better choice of course. However, I have run into a few cases of r…

> and "cargo check" can catch compile issues without a full build. You only have to compile when you actually want to test the behavior, which tends to be right on the first try more often as a result of the strict compiler.

When I meant compile I also meant cargo check. That still takes way longer than go builds.

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

#525

Post by josteinhylin »

yosefk wrote: post #51
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…

Uber reported that their Go code has quantitatively more concurrency bugs than code in other languages, and while to me it seems obvious from looking at Go's concurrency model, this is backed by actual data. Is there any quantitative data to back the claim that Go is better in an LLM based workflow than another popular language?

[flagged]

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

#526

Post by cute_boi »

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

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

#527

Post by otterley »

iscoelho wrote: post #363
gyesxnuibh wrote: post #301

Earlier quoted context omitted.

Having run a fleet of 100s of etcd clusters for 10000s of rps, and the fact that upstream runs tests similar to antithesis and recently partnered with antithesis [0], and jepsen has tested it long ago as well [1]. Etcd's raft algorithm is fine. Someone even did a TLA+ proof on it in the last couple years[2]. Yes there was a correctness issue a few years ago but otherwise the person you're replying to doesn't know wha…

"there was a correction issue" is downplaying it. Etcd is truly the worst example of Raft. Etcd corruption and loss of quorum is extremely common in practice and the GitHub issues sit for years. The design is simple, the performance is modest, yet it still has still never been reliable, despite being marketed as so. I can't speak to whether this is specifically due to their Raft implementation, but I'd argue the enti…

> Etcd corruption and loss of quorum is extremely common in practice and the GitHub issues sit for years.

Do these have reproducible test cases?

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

#528

Post by [deleted] »

fulafel wrote: post #414
xvedejas wrote: post #346

Earlier quoted context omitted.

Where would one ever read that Go is not memory safe? That's just a false claim, and anyone believing it would have probably gone out of business regardless of choice of programming language.

Nobody serious claims Go is fully memory safe. Here's Russ Cox telling you concurrency is a hole in the memory safety: https://research.swtch.com/gorace

[deleted]

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

#529

Post by sunrunner »

yawaramin wrote: post #519
sunrunner wrote: post #316

Earlier quoted context omitted.

Perhaps that company failed because it chose to port things to Rust and not because of Rust itself? Or any other number of reasons that survivorship bias might be mistaking.

Lol, so Rust is perfect until you actually try to do something with it.

I emphasised too much in that comment perhaps. I was going for because it chose to port things, meaning that maybe that company wasted time working on porting things instead of working on things needed to survive.

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

#530

Post by Mawr »

za3faran wrote: post #522
dnautics wrote: post #468

Earlier quoted context omitted.

i never run into these issues in >100k loc of productionized llm generated elixir (nil safety, type issues). i wonder, is there something architecturally in go that makes this a particular problem?

Up until quite recently, golang lacked generics, so `interface{}` was passed everywhere. It does not have typesafe enums (you can pass integers and it will compile). It has no way of declaring immutable structures. It does not have pattern matching.

> It does not have typesafe enums (you can pass integers and it will compile).

sigh. Sure, if you literally pass an untyped, hard-coded integer, like so:

    foo(100)
then, and only then will it compile. However, this won't:

    a := 100
    foo(a)
How horrific.
Post reply on HN