[jdbxhdd]

You realize that have of the features you are counting are now in Go while missing in the beginning exactly because people were missing them and Go simply did not offer a sane way to work around the missing features?

I'm also quite sure that Go will provide a more sane way to handle errors in the not so far future, since it's continuously at the top of people's complaints

[binary132]

your comment exemplifies the mentality, yes, and unfortunately it has now been adopted by project leadership, so I’m sure you are quite right that more “missing features” will get baked into the language soon :)

[int_19h]

It's far better to have those features well-designed and baked into the language once, then to have them constantly poorly redesigned and baked into every other Go app.

[binary132]

nobody would ever use this argument for the design of C. It’s good for C to stay lean and simple while communities using C (please let’s not with this imaginary monolithic “The Community”) are free to try things and offer competing solutions that others are free to ignore.

kitchen sink languages are bad. Justifying them with “well the community is bad, so we need the bad thing to be mainlined” is maybe worse

[int_19h]

C is legacy tech on life support.

By Go standard, all other languages are "kitchen sink". Conversely, I would argue that basics like decent error handling are not in any meaningful sense a "kitchen sink" thing.

[binary132]

C is still #4 on TIOBE, right behind Java, so that is not at all true.

Go is good because it’s not like the other languages.

It should stay not being like them, not try to be more like them.