[amscanne]

I think you're missing the point that I was trying to make.

Sometimes more features can make a thing worse. More advanced type systems may not necessarily make a large group of people more productive in a language, even if they are strict improvements. Go seems to have hit a sweet spot in terms of having just enough features to mostly get out of the way, and be otherwise straight-forward.

You could describe this part of its appeal as "worse is better". If you aren't careful about how you make something like that "better", you'll actually make it worse. I acknowledge this reality, while still personally wanting algebraic types, optional types, generics, etc. like everyone else. This gives rise to an "innovator's dilemma" of sorts for language designers.

(As an aside, if you look at the size of the Go team at Google, you'll probably be able to conclude that it's unlikely Google has put "hundreds of millions" into Go. But this is related to the core point: there isn't a huge list of language features that requires teams of experts to implement.)

[hajile]

Look over the SML types (not modules) and tell me where all that complexity lies. I'd argue that SML is both more simple than go (especially with this proposal) and more powerful. SML doesn't allow the shenanigans Haskell does (and a go using something similar to the SML type system wouldn't either).

As to hundreds of millions, that's easily true. Most of the people on that team make 500k per year at least with some making way more than that (and we aren't including other benefits of costs to the company who employs them). The language is publicly 11 years old and existed before that.

1e8 / 5e5 / 11 gives a mere 18 developers and less than 200 man years. I seriously doubt the compiler, libraries, and extensive tooling took less than 5x that amount at a minimum.

[amscanne]

Your estimate (> 90) for the number of people working on the core language is way off: https://github.com/golang/go/graphs/contributors

Re: SML types, I think you may be confounding simplicity and terseness. The last time I touched ML was decades ago, so I don’t have a specific opinion here but consider “both more simple and more powerful” could be a contradiction. The lack of power and expressiveness can in fact be part of what makes things simpler, not strictly because of the language but because programmers are forced to do things in a “dumber” way.