[btilly]

Because it makes a certain group of developers more productive. If you care about that or not is your decision. I'm not saying you should.

I would qualify that further.

It makes a certain group of developers more productive for certain kinds of problems. In particular they are more productive for rapidly creating relatively small prototypes. Particularly if performance is not a significant concern.

By the data that I've encountered (private and proprietary), using the features that make for high level languages, also make development in the large harder. And increase the cost of maintenance. You also get the issue that different parts of the code become likely to follow different styles. And the points where they meet are likely to become problematic.

If you care about that or not is your decision. I'm not saying you should. But these were the issues that the golang designers were attempting to address.

[valenterry]

I think you are quite mistaken. It is pretty much commonly agreed that powerful typesystems are not great for prototypes, rather the opposite, they allow easier maintenence of bigger codebases.

[btilly]

I have seen much in the way of opining that this should be true.

I have seen zero in the way of real-world maintainability data saying that it is true. Mind you, there is very little good real-world public maintainability data. And therefore I will say that, when I was at Google, I saw some of their private data, and it wasn't true there.

Specifically, most of the win from a type system is simply having one.

Mind you, the data that I saw includes some of the same data that informed the Go team's decisions. And therefore it is no surprise that it fits their ideas. Also that data was rather lacking on, say, real world examples of Hindley-Milner type systems. So maybe those actually work well in practice.

I also have reason to suspect that Rust's type system actually is a big win. Though I haven't seen actual data on it. But since Rust was in early development back when Go was started, it isn't a shock to me that Go didn't incorporate a lot of lessons from Rust.

So I am inclined to think that I'm basically right. However I would also classify my knowledge as only moderately well-informed. (But in a subject where I think that most people who chatter about it are essentially uninformed.)

[valenterry]

> Also that data was rather lacking on, say, real world examples of Hindley-Milner type systems. So maybe those actually work well in practice.

That is of course a bit disappointing, because anything below HM is _certainly_ not what I call advanced. But Google must be using some languages that use HM or a variant no? How comes there is no data about those.

[btilly]

When I was there, the three most widely used languages were C++, Java and Python. So that type of language had the most data. And so the analysis that I read focused on them.

Within those languages, projects that did a good job of KISS fared better than those which didn't. This lead to a discouragement from using advanced features. You'll see that bias in style guides like https://google.github.io/styleguide/cppguide.html.

[valenterry]

Well, none of those 3 languages are what I would consider "an advanced high-level language". C++ is not high-level by my definition and python and Java are certainly not advanced - well maybe Java has an advanced typesystem compared to Go, but not compared to the state of the art.

So I'm not surprised by the results, if the majority of the data came from those languages. That doesn't invalidate anything, it just changes the scope and can't be really used to backup your argument imho.