Hacker News Reader

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.

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.

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

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.

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"?

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.

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.

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.

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

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

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.

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.

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

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

> Few of the critics who "knew about programming languages" have created any language that ever made it into the top 10 programming languages in the world.

I often encounter some people in programming which I think lack humility. It's fine to question dogmas and the "big heads", but one has to look at the caliber of people you're up against and maybe give them the benefit of the doubt, if only a little bit.

I certainly wouldn't read a few PLT books and lambda-the-ultimate.org and then point to Ken Thompson and Rob Pike and say "your language has no <Type System thing>, you don't know what you're doing". These are not amateurs.

It's also doubtful they liked everything they put in, or disliked something they left out. Even Rust's creator didn't like some of the direction his language took.

If we were to ask other famous language designers they probably have a fonder feeling towards Go than people in this thread, knowing all of the hard design decisions one has to make to create an impactful language with an identity.

Right? So many complaints about "well but it's hard to make N-leaf tries in golang so we need generics!" It's like people believe the success of a programming language is correlated to its ability to express obscure computer science concepts unrelated to most peoples' jobs.

Golang works extremely well in practice, which is what I really care about.

And here I thought it was because:

1. repeating the same function definition and type declarations over and over varying only one type parameter and the name was a great way to introduce bugs if one of the functions was missed in updating.

2. working with reflection is slow and complex and easy to get wrong

Both of which are solved with something simple like generics.

If a goddamn list/vector requires built-ins from your language, you have already lost.

Golang is responsible for some of the biggest open-source projects out there and has a huge share of developers working in it. Lost… what exactly?

> The Go team was populated by people who had created one of the most influential languages of all time, C

Which is absolutely terrible from a programming language point of view, there were already better languages at its inception. Ken Thompson has a huge legacy in the CS world, but he is frankly not a good language designer at all.

Also, appeal to authority. If go were so good, it should able to be praised on its own accord.

Have you read Worse Is Better?

https://www.dreamsongs.com/WorseIsBetter.html

Go and C are good in a Worse Is Better way. They are not intended for writing the perfect and ideally engineered solution. They are designed to encourage pragmatic solutions to pragmatic problems, and therefore to become popular. And the features that make them suited to becoming popular are, in fact, tied to not trying to produce absolutely ideal solutions to the hard problems.

I am therefore praising them for being good at what they were designed to be good at. And pointing to their popularity is not an appeal from authority - it is a demonstration that they succeeded at their goal.

Those wouldn't have been as successful if AT&T had been allowed to sell UNIX at the same prices as VAX/VMS, instead of having source tapes available for a symbolic price.

It isn't as if C would have been a commercial success, had it come with a price tag.

Plan 9 and Inferno commercial successes, and Limbo adoption, are a clear example of how it would have gone instead.

One of the designers said that they had to dumb it down to the lowest common denominator Google engineer.