Go seems like a pragmatic fit, even though it was obviously not designed for LLMs and nor is it purely functional.

I review a lot of Go code, which means I review a lot of LLM Go code. Even though the human vs LLM authorship distinction has strong signals, Go's simple nature seems like a useful constraint on how LLMs can express themselves.

- Too verbose, too much noise e.g. error handling.

- Type system is too concrete, can't express sets or unions.

- Not much support for functional programming except passing closures

- Can't express immutability. Well, there's const, but it's crippled

These things mean Go falls short of what GP wants.

But Go has very distinct and (honestly kinda weird) design goals, it isn't really supposed to be "the simple applications language". It's supposed to be "C with NewSqueak", very much a systems programming language. You see that in its aggressively concrete type system

I agree it's easy to read. But you also have to read a lot of it, before anything interesting happens.