Oh, so, little bit of self-promotion: if you like Go but is frustrated with the ergonomics of it, I …

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?

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

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.

> 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 I think boilerplate & verbosity is an even bigger drawback with LLMs than human coding since context rot and "Lost in the Middle" phenomenon has so much effect on code quality It seems that LLMs benefit from semantic and syntactical density