[valenterry]

C is also a very low-level and close to the machine language.

Just because you can build a microchip doesn't mean you can build a spaceship and vice versa.

So I'm not surprised about that they e.g. left out generics and said they did so because they didn't know a good or right way to add them to the language. They were honest at least which I value a lot.

As to the success of Go that you mention. 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.

There are just currently way more junior developers due to the demand and the developement of the field.

However, you can already see that a lot of junior developers that started with Go are not so junior anymore and now that they got more experienced, they demand language features that make them more productive - like generics. And they will be added and in the end Go will be a language that is not simple anymore, it will be the new python.

Go is a very practical and pragmatic language, no doubt. It's one if its strengths. But it is not by any means an advanced high-level language in any sense that I would know of.

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

[Veraticus]

Not advanced or high-level enough for Kubernetes, eh?

Most senior programmers I know love Golang. It is easy to teach, easy to read, easy to understand, and easy to be productive in. And it is difficult to make unclear, complicated, or extremely bad code. A trade-off is that it is more verbose than other languages (if err != nil is a meme for a reason), but I think most people wind up prefer the clarity and correctness rather than hiding error handling.

[valenterry]

> Not advanced or high-level enough for Kubernetes, eh?

Let me ask you with two counter questions.

1.: which one do you think is more complex: kubernetes or the linux kernel?

2.: which lange do you think is more "advanced" or "high-level" enough by our definition: C or Go?

I think you can see where I'm going at.

Otherwise, I don't disagree with the rest. Go is the new cool python.

[Gibbon1]

Reframing a bit based on my own friends. The senior people I know like it because it's really easy to manage subordinates who are using it. And based on a few experiences I've had doesn't lend itself to the programmers wasting time on half baked mystery abstractions and broken internal API's.

[za3faran]

> Just because you can build a microchip doesn't mean you can build a spaceship and vice versa.

A recent incident of a submersible built by someone with aerospace experience comes to mind.

[valenterry]

Ha! I was about to write submarine but then I restrained myself from doing so. :X