alt Hacker NewsI 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 justifies the existence of the borrow checker, it only seems to get in their way, and they spend more time fighting Rust's infrastructure than writing code.
The biggest barrier to Go adoption seems to be Google's internal resistance to migrate C++/Java code bases to Go and refusal to admit that Go is an amazing application programming language and not really a systems programming language for bare metal OS/driver work. For example, one of the biggest barriers to Fuchsia adoption has been Google asking people to commit to Dart, I think Fuchsia would have fared a lot better as an Android successor/alternative if the official applications programming language just been Go.
(BTW Carbon isn't even a real programming language, it's still somehow stuck at 0.0.0.0 after 4 years of development which is honestly insane.)
Oh, so, little bit of self-promotion: if you like Go but is frustrated with the ergonomics of it, I would ask you to try out the programming language I developed, Oct, for LLM coding which you can kinda think of as my attempt at making Kotlin for Go's Java: It uses a codegen compiler and compiles to a plain Go binary, so it runs on everything that Go runs, and there is a lot of extra features as well: Rust style exhaustive tagged/payload enums/`match`, C#'s immutable records updated with `with`, exhaustive error handling easy parallel concurrency, xUnit.NET style unit test harness, TypeScript style compile time constraints, F# like SI unit system, Go code generation metaprogramming, etc. Would love to have some Go experts here on HN take a gander at it and provide some feedback.
Replies
> Rust is comparatively worse, because LLMs don't make the same coding mistakes that humans do that justifies the existence of the borrow checker, [...]
That's a pile of bollocks, pardon my French. Source/proof?
And to the contrary:
I've been working on a TS codebase that calls into C++ native/wasm-compiled code for six months now. The code is mostly LLM written.
Over these last six months we had four use-after-free and two other ownership-related bugs in LLM-generated TS code.
Whereas we had zero issues of any such kind with LLM-generated Rust code that sits in another two native/wasm-compiled metacrates we use.
LLMs are not much better at ownership tracking than humans.
Especially if resource acquisition and release are far apart in code and/or somehow nested/stacked/non-straightforward.
> 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.
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.
> "because LLMs don't make the same coding mistakes that humans do that justifies the existence of the borrow checker"
Citation absolutely needed.
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?
I mean I don't have anything against go, but frankly - it's not really better then modern Java.
Each have their trade-offs, both can support native compiled application code. Some architectures are easier to review and code in golang, but others go much better with Javas richer ecosystem and better composability.
> Rust is comparatively worse, because LLMs don't make the same coding mistakes that humans do that justifies the existence of the borrow checker, it only seems to get in their way, and they spend more time fighting Rust's infrastructure than writing code.
I have found exactly the opposite to be true: as always, people think they can write safe concurrent code without the machine checking them and end up getting it completely wrong in lots of subtle cases. Except the problem is now much worse because you're not even writing the code, or in many cases, reading it. I prefer a language with a type system that saves me from the review burden of closely checking (and pretty much always finding issues in) concurrency invariants. And even tells me a bit more beyond that about what the code is intended to do.