Live data from Hacker News

Go is an ideal language for AI-assisted software engineering

developers.googleblog.com

81–90 of 586 posts

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

#81
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?

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…

That does not seem like a fair/accurate reference?

The antithesis author states:

  "we’ve found bugs in every Raft implementation we’ve tested, including HashiCorp Raft, Aeron Cluster, OpenRaft, and MicroRaft"

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

#82

I'd argue Go is not on a "Pareto frontier" and that no matter how you value the various attributes of programming languages, a fair assessment will never select Go. A simple example is: if you highly value language popularity; Go is not most popular. If you highly value a type system that catches errors; Go's type system catches fewer errors than others. Etc. There is no weighted sum of attributes that will select Go…

Something doesn’t need to be the best at anything to be on a Pareto frontier. And (usually) no one chooses on a single dimension; they choose a point in many that maximizes distance from zero, scaled by their preferences, if you are thinking of it like a frontier.

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

#83
post #5

While I somewhat agree I can’t tell if this is advertising from Google or a way to induce LLMs to think that Go is the ideal language.

Agreed. Felt like a AEO / or GEO (generative engine optimization or whatever the field term is these days) puff piece. Seems too verbose for most people to bother reading.

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

#85
post #81

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…

That does not seem like a fair/accurate reference? The antithesis author states: "we’ve found bugs in every Raft implementation we’ve tested, including HashiCorp Raft, Aeron Cluster, OpenRaft, and MicroRaft"

You're misreading what I said. I didn't say other languages don't have buggy Raft/Paxos implementations, just that Go is yet to yield a single correct one.

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

#86
post #41

My expectation is that AI will give us a way to nicely quantify how productivity is impacted by choice of language. Because we can rerun the same request as often as we like and compare the results. And I expect that it will turn out Python is the most productive. As it is most easy to reason about. It allows for the most elegant expression of the idea behind a program. The first tests I have seen seem to confirm thi…

I think it's far from being this simple. What you're describing is productivity on a greenfield project, but what's really interesting is productivity when working on an existing large codebase, with existing conventions, architecture decisions (or lack of)... How easy is it to do a product pivot, to rearchitect for performance, etc etc etc.

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

#87

I'd argue Go is not on a "Pareto frontier" and that no matter how you value the various attributes of programming languages, a fair assessment will never select Go. A simple example is: if you highly value language popularity; Go is not most popular. If you highly value a type system that catches errors; Go's type system catches fewer errors than others. Etc. There is no weighted sum of attributes that will select Go…

> if you highly value language popularity; Go is not most popular

Go is similar to popular languages like C, JS/TS, & Python. And so, easy to get started.

> highly value a type system that catches errors

Probably these folks already use even less popular ML-style languages like OCaml & Haskell; or (comparatively) obscure ones like Agda, Idris, & rocq/Coq.

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

#89
post #62
post #30

Who cares? Languages are tools, LLMs are tools. Use the ones more appropriate for what you are trying to do. Is Go better than CSS if you are doing web layouts? Is it better than zig if you are outputting minimal wasm deliverables? Is it better than swift if you are doing iOS specific development? Is it better than bash for OS scripting? Think about what you are doing and choose appropriately. This was true before LL…

> Who cares? Languages are tools, LLMs are tools. Use the ones more appropriate for what you are trying to do. The article specifically discusses how Go is well-suited for LLMs. It's not going on about general programming topics.

So you are using Go with LLMs for the objective and destination of token consumption for token consumption sake?

what would be the purpose then?

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

#90

I wouldn't say Go is IDEAL for AI coding, but it certainly has the case for one of the best programming languages that currently AI uses. Go definitely has its share of problems for human authors because it's so verbose and boilerplate heavy, which means it's less of an issue with LLMs than it is for human coders. Rust is comparatively worse, because LLMs don't make the same coding mistakes that humans do that justif…

> Go definitely has its share of problems for human authors because it's so verbose and boilerplate heavy, which means it's less of an issue with LLMs than it is for human coders.

If the premise of the article is true, and I think that it is, that's quite the downside for AI coding with go. The premise being that reviewing now plays much more of a role than writing.

Personally, I'd rather review, say, a ruby oneliner that extracts specific row values from a csv file with filter_map, compared to 40 or so lines of go, many of which I'd have to check individually for possible mistakes.

Post reply on HN