[btilly]

Well, let's be honest: it targets junior developers, or at least that was originally a major goal. It is backed by Google and is marketed.

It actually targeted Google developers. It was a 20% project that was not backed by the company officially. Official backing only came *AFTER* others were convinced internally that it was worthy. Their marketing budget started at a grand total of $0.

So it stated with NONE of the factors that you cite as its advantages. Though, to be fair, its core team includes people who a lot of programmers respect.

... they demand language features that make them more productive - like generics. And they will be added...

You mean already were added about a year ago. See https://go.dev/blog/go1.18.

... it will be the new python.

Interestingly, internally at Google it replaced Python. As a reasonably fast to develop in language, with substantially lower maintenance costs. And let me assure you, Google has done a lot of work on looking at what both development and maintenance cost them internally.

But it is not by any means an advanced high-level language in any sense that I would know of.

Can you provide a reason why we should care about a language being "an advanced high-level language"?

[valenterry]

A programming language "starting" is usually a longer period of time, at least by my definition. Not the first year or so.

Also, that go targeted junior developers were the authors words, not mine.

Last:

> Can you provide a reason why we should care about a language being "an advanced high-level language"?

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.

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