[amscanne]

Just to get your argument straight: nothing comes close to the level of utility and usability of StandardML, Ocaml and Haskell?

So why haven’t aren’t those languages commonly used?

The simple answer is that there’s a lot more to a language than its type system. Go is popular because it’s simple. Throwing generics on the language without a lot of deep thought and time risks adding marginal utility while destroying a large amount of the core simplicity. While I too want generics, I understand that the caution and skepticism of the core team is not “Hubris and NIH”.

[tome]

> Just to get your argument straight: nothing comes close to the level of utility and usability of StandardML, Ocaml and Haskell?

I suspect hajile meant that no type system comes close to the utility of that of StandardML, Ocaml and Haskell, not language in general.

[hajile]

I was specifically talking about types.

Java or C# decide null is bad and try very hard to add Option and non-nullables, but go's creators just decide they must not have a good reason, so nulls everywhere.

The potential problem of things like empty interface escaping the type system are well known, but go's creators decided that everyone else's experience here didn't really matter, so you get not only empty interface, but it becomes the only way to do certain things because of the lack of generics.

Speaking of generics, every popular multi-use language winds up building in generics or tacking them on later. Go's creators denounce all other solutions as lacking.

What makes them think they are so incredibly special that they don't need to learn from the experience of others? It seems to me that the only reasons are basically ignorance or arrogance and I don't think they are ignorant.

> So why haven’t aren’t those languages commonly used?

Languages don't generally survive without a big corporation paying the bills. If Google had chosen to put their hundreds of millions into SML instead of golang, the world would be a very different place. The first company to give such a language a chance was Mozilla with Rust and we can see how popular it has become. You could view Rust as SML with c-like syntax, lifetimes, unsafe options, no GC, extra pointer complexity, macros, etc. A bit more potential power at the cost of orders of magnitude more complexity due to being targeted at a different, lower-level problem set.

> Just to get your argument straight: nothing comes close to the level of utility and usability of StandardML, Ocaml and Haskell?

I would argue that SML is the best of those three languages and the most comparable to go as well. It's designed to be pragmatic, easy for first-year students to learn, and easy for later students to implement in compiler classes.

Go's headline feature (goroutines aka channels) have been implemented in PolyML or CML a decade or two before go existed and they did it in a type safe manner. Go has multi-value returns, but all that means is that it has partial tuple support unlike SML which has both tuples and pattern matching. Despite what you might think you know from Haskell, SML allows mutation complete with safe (and type safe) pointers.

Rather than interfaces, SML has structural typing which allows most of the same features, but with type safety and generics. There's also sum types (basically union types) which are easy to use with pattern matching and guarantee that all union types are handled safely. Unlike go with nulls everywhere that must be checked at your own peril, SML uses option types and nothing is ever null.

All of that said, I don't hate go. I believe the language could keep its existing syntax while adding most if not all of these features and retaining a decent amount of backward compatibility and making code both more terse and more readable. It could solve its generics issue while also solving its other type problems and potentially picking up extra performance on the way.

[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.