Live data from Hacker News

Go is an ideal language for AI-assisted software engineering

developers.googleblog.com

91–100 of 586 posts

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

#91
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…

> Is it better than zig if you are outputting minimal wasm deliverables? Which tradeoffs are you willing to accept? Zig (along with several other languages) is superior in a lot of ways for that type of job, but I still settled on Go for a particular minimal WASM (browser) project. It wasn't my first choice, but it was where I ended up because LLMs kept going out to lunch in other languages and I didn't have anywhere…

the Go runtime comes along for the ride when producing a wasm file, if you are interested in "minimal" (as in small or without extra cruft) then languages that do not require such a thing might be more adequate

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

#92

The killer feature of golang for LLM dev is the tooling. forbidigo is what allows me to keep ambient config out of my app, and restrict file access to a small set of paths. The coverage tool has "nocover", so you can guarantee that every realistic path is exercised at least once ("100%" code coverage, which is not a marker for testing completeness, but rather for flagging code you forgot to test). Linting is really g…

[deleted]

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

#93
post #89
post #62

Earlier quoted context omitted.

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

Read the article to find out.

Token use didn't seem to be a criteria from my casual reading, but maybe you can illuminate me what section pointed to that, I may have been too superficial in my reading

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

#94
post #6

Earlier quoted context omitted.

Personally I find Rust a lot harder to read than Go. If you're going to have an agent write most of your code readability is very important.

I have an agent read most of the code as well. The agent explains things to me in plain english. The default sentiment is humans should read code it's more progressive and a leap of faith to start giving that up. Obviously, I get why you feel humans still reading code is important, but if you look at the progress of AI for the past couple of years, that gap is closing. The trendlines speak of a future where it become…

I have a few utility go codebases that I simply do not read at all - but it's internal tooling so there's literally no point in reading it when the LLM can modify it in seconds to do new things.

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

#95
post #23
post #6

Earlier quoted context omitted.

Personally I find Rust a lot harder to read than Go. If you're going to have an agent write most of your code readability is very important.

For whatever reason, maybe not even logical ones, Go repulses me. I don't know why exactly, I like the idea of Go, but the aesthetics rub me wrong. I think it's the use of pointers and "if err != nil {}" error handling spam. It reads as a highly compromised imitation of Python and C rather than a solid execution of some other idea. Rust is not the most beautiful language out there but it doesn't trigger any such reac…

For me it's mainly the if err != nil {} stuff and the fact that everything is package scoped (C-style enums and constants).

You can pretty clearly see the limitations if you read, for example, the type of code the Protobuf compiler generates when trying to compile Protobuf/gRPC enums or structs into the way-more-limited Golang type system (this is despite the two being designed to work together). And it could really do with algerbraic data types and other modern programming language features.

Also the type system does have a couple weird behaviors that seem straight out of JavaScript. Like the difference between struct and interface nil for example:

```

var buf *bytes.Buffer = nil

var out io.Writer = buf // now out is nil

if out != nil {

    // This block will execute because out is not nil

    out.Write([]byte("crash")) // This line will crash because out is nil
}

```

Many things about the language almost seem to be designed to simplify the implementation of the compiler rather than to benefit the developer experience.

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

#96
post #51
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

#97
post #51
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?

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

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

#98

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 doesn't have any kind of story for incremental migration from C++ or Java; you are talking about rewriting all those codebases from scratch, which is an obvious nonstarter as long as engineering resources are finite.

IIUC Fuchsia uses Dart mostly for UI stuff and Go has never really tried to be competitive there? I don't see much of a reason to suppose this is a serious bottleneck to Fuchsia adoption, as opposed to the obvious reasons why it's hard to displace an existing OS with a huge install base.

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

#100
post #80

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…

So in terms of the mainstream languages, what would you say would be the most ideal language? (At least until Oct takes off!). Perhaps modern Java? .. Or even Zig?

For what purpose? Different use cases require different language features.
Post reply on HN