Live data from Hacker News

Go is an ideal language for AI-assisted software engineering

developers.googleblog.com

11–20 of 586 posts

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

#12
post #2

Rust is better. It just is. Go is not bad. But as a long time go advocate, the hurdle for my teams using rust is gone, and thus everything is now rust.

Ignoring performance for the moment (because most situations are bottlenecked on something else), why is rust better?

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

#13
post #2

Rust is better. It just is. Go is not bad. But as a long time go advocate, the hurdle for my teams using rust is gone, and thus everything is now rust.

idk. In my experience the build/compile experience has been far worse esp for fast iterating. Even concurrency models did not seem as intuitive as Go's. Im no systems expert - have deployed practical and performant distributed systems though.

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

#15
post #6
post #2

Rust is better. It just is. Go is not bad. But as a long time go advocate, the hurdle for my teams using rust is gone, and thus everything is now rust.

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 becomes less and less important.

This was exactly what happened with writing code. Now most people don't write code.

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

#17
post #10
post #2

Rust is better. It just is. Go is not bad. But as a long time go advocate, the hurdle for my teams using rust is gone, and thus everything is now rust.

Zig seems to have more closely aligned with what Go devs prefer.

Go doesn't have memory safety issues because of its GC, while Zig has UB problems. Zig might have slightly better performance, but I don't think choosing a language without memory safety is a good idea

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

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

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

#19
post #6
post #2

Rust is better. It just is. Go is not bad. But as a long time go advocate, the hurdle for my teams using rust is gone, and thus everything is now rust.

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.

Counterpoint: I find Rust easier to read.

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

#20
post #4

Earlier quoted context omitted.

can you elaborate?

Rust compiler is a tyrant. Type system is strict. Borrow checker is relentless. LLMs can't slop too much without being beaten up by the compiler.

This is true. I'd like metrics on this though. It could be that LLMs find go easier so they end up writing better code and rarely hitting static errors like a human would in rust. IT could be through scientific measurements that the benefits of static checking could be negligible for LLMs.

No way to know until someone does the science on this. Until then it's just people saying that more static checking is better. But I do think, anecdotally, python is horrible for LLMs.

Post reply on HN