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

361–370 of 586 posts

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

#361

Post by frollogaston »

maleldil wrote: post #360
frollogaston wrote: post #285

Earlier quoted context omitted.

This back-and-forth is a good example of why Go benefits from having a centralized linter. And uv isn't the official Python package manager even though it should be.

I don't get why this is a big issue. This isn't some recurrent decision to be made. It's something a lead decides once and the project follows. That's it. Many companies have style guides anyway (eg Google[1]); the choice of a formatter is much simpler. [1] https://google.github.io/styleguide/go/

Because at some point you have to interact with some other team or project that made a different decision. And whatever you picked might fall out of favor and lose support. There's already a graveyard of Python type linters, including Google's pytype.

Especially the uv thing. You clone some non-uv git repo that has no pyproject.toml and you don't know what to install. Maybe has requirements.txt but it's partially wrong.

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

#362

Post by maleldil »

joaohaas wrote: post #348
bushbaba wrote: post #344

Earlier quoted context omitted.

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.

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

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

#363

Post by iscoelho »

gyesxnuibh wrote: post #301
Thaxll wrote: post #218

Earlier quoted context omitted.

I'd like to know what you base your statement on that the Raft implementations in etcd or CockroachDB are incorrect. Your original paper does not mention those implementations, so where does that claim come from?

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 entire codebase is over-engineered and questionable.

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

#364

Post by pstuart »

amazingamazing wrote: post #97
yosefk wrote: post #51

Earlier quoted context omitted.

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?

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/ )

That article is meh. All of those issues are either addressed or junior programmer mistakes.

Yes, it's a bit of blame the user which will likely get the retort of "but I thought Go was perfect for junior engineers?"

Yes, there are footguns but none of the points therein were compelling.

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

#365

Post by eudamoniac »

odo1242 wrote: post #156
henrymerrilees wrote: post #133

Earlier quoted context omitted.

Is there a language that you would argue is at least as good as Go at everything and better than Go in at least one thing? That would be the most straightforward way to argue against its Pareto optimality. Listing particular sets of preferences for which Go is not optimal is not sufficient unless you can show the list to be exhaustive.

I'm not GP, but for me that would be TypeScript. TypeScript's tooling is as good as Go's across the board, it's very readable, it's a simple language, it has very few footguns, and it compiles fast. But it has better type safety than Go. This isn't an exhaustive proof as no language will every be fully Pareto optimal in practice (it's just not possible, there are too many dimensions), but I'd argue it's at least some…

Typescript is single threaded and 2-10x slower and does not compile into a binary.

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

#366

Post by FireBeyond »

rubiquity wrote: post #175
jibal wrote: post #162

Earlier quoted context omitted.

Even if so, the "You're misreading what I said" charge was bogus and it would be nice if you admitted that. Edit: > What are they implying by citing that? That Raft implementations in all languages have bugs? That's what it says. > I've already pointed out that is false. You claimed that, and it's being disputed. > Please let me know, since you're so comfortable speaking for them. This has veered into bad faith ... I…

But they are misreading what I said. My original post is clearly about Go. What they wrote is also ambiguous. > The antithesis author states: > "we’ve found bugs in every Raft implementation we’ve tested, including HashiCorp Raft, Aeron Cluster, OpenRaft, and MicroRaft" What are they implying by citing that? That every language has a Raft implementation with bugs? Yes that's probably accurate because lots of people m…

You're being very mealy-mouthed, even here, it reads as "The pre-eminent Go implementation can't even get it right" and yet the implementations Antithesis tested in Rust are apparently people's random "fun and learning" projects, nothing serious, and certainly not all the proprietary implementations that you've used that are all correct.

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

#367

Post by gyesxnuibh »

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…

Their lock, leader election, sessions, and leases are all awful and I'd never recommend anyone to use those. But as a strongly consistent kv store and if you need the watch mechanics, its useful. It has its place and that's mostly being used by kubernetes.

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

#368

Post by ReactiveJelly »

xvedejas wrote: post #346
HAL3000 wrote: post #242

Earlier quoted context omitted.

> Go is bad so "I reach for Rust, Zig..." I hope my every competitor will take your advice to heart, as one of our competitors did when they read that "Go is not a memory safe language", so they wrote a blog about how they are porting to Rust. While our team was moving fast and using those "primitives that should almost never be used" around our long running production code base with success. Some time has passed and…

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.

It looks like Go is memory safe for single threads and channels, but not for shared memory between threads: https://en.wikipedia.org/wiki/Go_(programming_language)#Lack...

> Go's internal data structures like interface values, slice headers, hash tables, and string headers are not immune to data races, so type and memory safety can be violated in multithreaded programs that modify shared instances of those types without synchronization.[113][114]

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

#369

Post by throwaway2037 »

osigurdson wrote: post #336
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…

If you know any other language, you basically already know Go (with the exception of the channels stuff). The biggest pain is the if err != nil stuff, which I know some people like but it is suboptimal in my view. While far better than C# and Java's exceptions, far worse than Zig's model.

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

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

#370

Post by gpm »

xvedejas wrote: post #346
HAL3000 wrote: post #242

Earlier quoted context omitted.

> Go is bad so "I reach for Rust, Zig..." I hope my every competitor will take your advice to heart, as one of our competitors did when they read that "Go is not a memory safe language", so they wrote a blog about how they are porting to Rust. While our team was moving fast and using those "primitives that should almost never be used" around our long running production code base with success. Some time has passed and…

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.

By a strict definition of memory safety it isn't - you can tear two-pointer-wide values using data races and cause arbitrary memory issues if you try to using only normal code.

It's close enough for most purposes... but it isn't.

Post reply on HN