[zozbot234]

> easy to learn, ... easy to read and maintain,

These things are quite subjective. In practice though, Go lacks the kinds of features that would make very large scale codebases (the sorts of codebases where "many coders ... work on the same thing") truly surveyable, understandable and easily maintained. I mean, it's not a complete disaster like Python or JavaScript. It has some features to support modularity and programming "in the large". But other modern languages like Rust or even Swift are quite a bit better on that side of things, and it shows.

[usrbinbash]

> In practice though

In practice though, there is a reason why Go is seeing continuous growth in usage, so I kinda doubt that these features of Go are subjective.

> But other modern languages like Rust or even Swift are quite a bit better on that side of things, and it shows.

In what metrics does that "show" if I may ask? Because it isn't showing in usage numbers across projects.

[ramses0]

There's an aside to that: Supposedly within google itself, they have super-magical tooling (ie: rename `dev.foo.bar(abc)` to `abc.dev.v2.foo(bar)`), so it's less important to have those "in the language", when "they" can just refactor "everything".

Us mere mortals are trying to pick up Thor's hammer at the end of the day.

[abenga]

And yet the largest Go projects seem to be doing fine, dwarfing the largest Rust or Swift projects in the level of activity, number of contributers, and general impact on the ecosystem. And I speak as someone who prefers to write Rust.

Perhaps these features you speak of don't matter as much as we think.