Live data from Hacker News

Go is an ideal language for AI-assisted software engineering

developers.googleblog.com

431–440 of 586 posts

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

#432
post #49

I like Go but a couple of these "advantages" wash out when you add the scale and typical usage patterns of agents. | Go is Readable / Go is Maintainable It's true that Go, as a low-magic language, tends to be very same-y looking across projects, which is incredible for being able to reliably understand your dependencies' source code. And its tooling is world-class. I love this about Go. But in practice I've found tha…

My problems reading code are understanding what the new vocabulary actually means, what it does in context, why it exists, etc. Doubly so when someone is pinging me to review a new 13000 line AI MR every 24h. Understanding an individual line because of some complex C++ feature, I don't remember it ever being an issue.

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

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

How dare you suggest having fun! Pay attention! We’re trying to have a language flame war here!

Hahah thanks for noticing that, also Lisp in all caps, like the original from the 60s

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

#435
post #418
post #402

Earlier quoted context omitted.

Good point. It's sometimes challenging to get a Rust program to compile... but if you do, it's probably going to work.

The authors make some good points: compile time and test speed matter, platforms matter. But they really dodge the whole “guardrails matter” thing. And guardrails are going to win long term. As for readability, the fact that AI-written Go closely resembles human-written Go is not necessarily a point in Go’s favour.

> "guardrails matter" This thing has been solved in the 70s. Basically, have a powerful type system, and a compiler that beats you into submission when you try to stray from the straight and narrow. Languages like (S/OCa)ML, Haskell and Rust will bring this to you. As a consequence, you fight the compiler, and once it submits, you have a good chance it's going to work. The compiler is also the ultimate refactoring tool here. Change the concept? Just change the type in the code and follow through by fixing the error messages the compiler spits out.

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

#436
post #33
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…

> For a language team, Go is a dream. I agree very strongly. There's no debate about things that have 1000000 permutations in other languages. e.g. The correct format can always be checked by `go fmt` with no real config options. the end.

[dead]

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

#437
I will leave this prediction here and maybe come back in few years:

1. JS is mem-safe, single-threaded, and there are lots of training data. Easily my first choice. I'd put Python here as well, although I don't like it personally. Both should be used with "avoid external deps" in your AGENTS.md

2. Go might be a good second choice. Simple language, IMO good primitives for concurrency, well-designed std, therefore smaller potential for supply chain attacks.

3. Elixir/Erlang, little training data but rising. Safe language, safe concurrency, immutable, scalable, there are some many advantages... It has been avoided because it's different but that could change drastically in the age of LLMs.

4. Rust is probably next choice, along with C++, because while Rust is safer, the language is quite complex. C might be here too, there is a lot of training data, but every project is different and the language is very unsafe.

5. Zig, I really like the language, but it is terrible for LLMs, mainly because it's constantly changing, and the std is also under-featured and IMO weirdly designed. It's a fun language for hobby hacking, which I believe is not going anywhere, it's just not going to be something you will be payed for.

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

#438

I will leave this prediction here and maybe come back in few years: 1. JS is mem-safe, single-threaded, and there are lots of training data. Easily my first choice. I'd put Python here as well, although I don't like it personally. Both should be used with "avoid external deps" in your AGENTS.md 2. Go might be a good second choice. Simple language, IMO good primitives for concurrency, well-designed std, therefore smal…

I mostly use Elixir and JS, and I'm constantly surprised by how much easier and better the code quality is in Elixir, especially given the much smaller training data. I've started to use it for all my personal projects. I think Elixir's terseness, introspection capabilities, and strong ecosystem-wide quality guards really help.

At work, we use C#. I'm shocked at how much worse it is. I've also used a bunch of Python, but I still feel the quality isn't as good as the codebase grows, but I didnt put as much effort trying to improve it.

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

#440
I can't help but think this is Google attempting to poison the training data for future LLMs to incentivize them to pick Go.

Rust or Nim are really the ideal targets for LLMs and will continue to grow. As LLMs write more code and as humans review less, it will be more important to have confidence that your code doesn't run into a weird one off runtime heisenbug issue.

Post reply on HN