I've not seen this in my experience tbh, the extra code that Go requires is ugly but not complex, the lack of ergonomics actively discourages "clever" solutions and, as a result of this, people tend to write the kind of straightforward code that doesn't end up needing lengthy programming or intense debugging.

At my workplace we've used many languages over the years (C#, Python, Go) and Go teams are the ones that by far do the least amount of yak shaving and have the most intelligible codebases.

I’ve always felt like the lack of many complex language features nudges teams to also keep their code simple.

There is always two aspects to a language works in practice: how it formally works, and how the community uses it.

Go is (was?) simple, and also (encouraged by the language and influence from its developers) the community mostly aims to keep the usage simple.

It’s the lack of parametric enums (sum types) which really gets me. I use sum types constantly. Nearly as often as I use structs.

For example, in typescript you can define a json value as something like:

    type JSON = null | bool | string | number | [JSON] | {[k:string]: JSON}

Go forces me to reach for interface {}, and use a nest of dynamic dispatch code. It’s horrible. Go code is harder to write, harder to read and it runs slower as a result.

The decision is baffling. Especially given go now has generics, which are waaay more complex than enums. And sum types in go could be used to fix the constant (result | error) boilerplate. And remove nullability. Sigh.

100% also our experience. We have an internal CLI which has grown to almost half a million lines of Go, mostly contributed to by first-time gophers (and agents nowadays), and with relatively little work spent on making sure the core entities and interfaces encourage doing the right thing, the entire codebase is still surprisingly readable and free of unexpected behaviors.

It's hard and annoying to read though. Constantly beating around the bush, circling the point but not stating it, not unlike LLM prose.

Yep. But with go 1.22/1.23 and later this is changing. It's becoming a hell of a mess like many other big languages. I think it was two consecutive releases back in 2024 where they added for ... range and generics? That was when I gave up.

Sad that the one language that managed to occupy that nice spot in language design space for an extended period of time, isn't doing so anymore.

Of course, you can actively restrict yourself to standard go, but not needing to do that was the whole point.

The support for iterators is relatively new, though being limited to data structures that an iterator makes sense on, they don't exactly get around in the language and pollute everything everywhere.

The support for generics is years old and I don't believe anyone who claims it has ruined the language. I've barely encountered them in the wild and I've never encountered the thing people were really worried about in the wild where something has 4 generic parameters that are themselves complicated generic parameters of other things. If you're encountering that, it is either some one-off library I've never encountered, or it's because you or your team are writing it, to which the solution is, stop that.

I'm not even sure I've yet seen a "generic" in a library in Go that isn't simply straight up a generic data structure, the core use case for generics. I've written a couple of such things but they're all internal code.

I'm coming to think there's a selection effect here. The people that want to write complex code feel unsupported by Go and avoid it.

Yep. I'd much rather 50 lines of rust than 100 lines of go. I find shorter programs to be generally easier to read and more likely to be correct.

This is good for Go ecosystem!

So… what language do you use?

No (useful) language is simple. Claiming go is not simple without naming a language for comparison is a party foul.

Rust. Typescript. More complex languages let me write shorter, simpler programs.

I don't write haskell, but I understand the appeal. Haskell is this philosophy taken to its natural conclusion.