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

61–70 of 586 posts

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

#61

Post by kstenerud »

jerf wrote: post #35
kstenerud wrote: post #7

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…

"The only thing I haven't found is something to enforce error handling." errcheck, generally as manifested in golangci-lint, ensures you can't forget to do something with them. It would be odd for you to know about forbidigo but not errcheck as the former is much less widely known; is there something that errcheck doesn't do for you? It's worth pointing out that "discard this error on purpose" is a legitimate form of…

The rule I set for linting when an LLM is writing code is: Either you adhere to the rules, or you mark an exception with a valid reason.

https://github.com/kstenerud/yoloai/blob/main/docs/contribut...

Poor defaults break systems by a thousand cuts. They seem to make sense when designing the language (more convenient, less typing, etc), but then they very quickly become liabilities as project complexity increases. Go made the mistakes of mutable-by-default and silent-error-dropping, but their cyclical-import-forbidding was a good call.

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

#62

Post by runjake »

hugodan wrote: 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.

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

#65

Post by brunoarueira »

I couldn't agree more, but the following sentence is a little biased:

> Gophers often speak of how they love that they can never tell who on their team wrote a particular piece of code—it all looks the same.

Multiple languages can have a degree of understabillity, but what matters most is context, because sometimes we need to code in a way to solve a specific problem like performance and it should be kept as is.

Another side subject I should add is about test coverage, although code is cheap, mainly because AI, guarantee that new changes to a stable code should continue to work as expected.

I worked on a few go projects with bad structure and some of them with really low test coverage (e.g. 8%), so part of the post resonates with me about we as software engineers should pursuit good architecture and other skills to allow long term maintenance.

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

#66

Post by ndriscoll »

orangecat wrote: post #47
_verandaguy wrote: post #28

Earlier quoted context omitted.

I'll qualify this from my POV (which may be different than GP's). Go's historic maintainability strong suit has been its simplicity and consistency. The syntax is, relatively speaking, lightweight, the language invites complexity through composition, and information density for any unit of code is typically quite low (which isn't necessarily a bad thing). In my opinion, though, these are all drawbacks, and Rust addre…

Yeah, Go is easy to read in the same sense that English limited to its ten hundred most common words is easy to read ( https://xkcd.com/1133/ ). Whether that nature is helpful or harmful to LLMs is an interesting question.

It seems very obviously detrimental to me (in the exact same way it's detrimental to people); e.g. use proper jargon with an LLM and you find it is suddenly an expert. The LLM has no trouble at all perfectly fluently using macros or monads or whatever thing people are afraid of to write simpler, more concise code that directly expresses the business logic in a fully type safe, high performance way that the compiler can introspect for even more information. Go of course lets you do none of those things and can only ever be used for "beginner code" by intentional design.

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

#67

Post by furyofantares »

I theorized this about a year ago and had a good amount of success vibing small game projects in Go.

I still think Go is a very excellent choice but I have switched to, of all things, AssemblyScript within a Rust host. I've been very happy with it - surprisingly so. Compile time is a major drawback of course.

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

#68

Post by runjake »

Buttons840 wrote: post #55

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…

Here's how my assessment selected Go (long before LLMs):

- I had to write a moderately complex program. I didn't want to do it in C, and I didn't want to learn Rust.

- So I spent roughly about 2 hours becoming familiar with Go and playing around in Go playground. I decided that this would work.

- And then I got started on my program and I was immediately productive and that software is still running today, along with all the other stuff I've written since then.

Programmer productivity is excellent with Go. And it has a thriving ecosystem. Of course, some things could be better, but I don't really have much issue with it's error handling or types.

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

#69

Post by threethirtytwo »

eliasson wrote: post #26
threethirtytwo wrote: post #15

Earlier quoted context omitted.

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…

> Now most people don't write code. I use LLM daily to write code for and "with" me, I also write code without LLM. Most people I come across mix it up. A few do it all by hand, and equally few all by LLM I would say. Is that just in my corner of the world?

The trendlines are moving away from this. It's all happening so fast that not every company is on the same page, but from what I see we are quickly converging on not writing anymore code.

My entire company for example does not write a line of code. We manage agents and that's it. Many, many, many companies and people are already doing this.

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

#70

Post by threethirtytwo »

simonw wrote: post #18
threethirtytwo wrote: post #15

Earlier quoted context omitted.

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 don't read all of the code produced by my agents any more, but I like to reserve the ability to do so if I run into a particularly confusing bug, or for any code that's security adjacent.

Same. But usually if I need to read code, I end up telling my agent to summarize it for me.
Post reply on HN