Hacker News Reader

Comment by zerr | Hacker News Reader

It was due to the arrogance and incompetence of a couple of ex-AT&T authorities in the team.

Have you even looked at other languages' implementation of generics? Java's implementation takes up a significant part of the language spec, compiler, and VM for example.

Here's an insightful comment from some time ago, explaining why it's a technical issue, not a political one: https://news.ycombinator.com/item?id=9622417 It links to this FAQ highlighting a LOT of the complexities and pitfalls of generics in Java, things that are all to easily overlooked by armchair language expert: http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypePa.... Note that that's just one chapter in a very large document.

Comments like this say more about their author's arrogance than that of the Go language team.

Which part of the JVM is complicated by generics? They're type erased so the VM shouldn't really care. The compiler on the other hand has plenty of complexity...

To me, "takes up a significant part of the language spec, compiler, and VM" isn't a meaningful reason to exclude something from a language, unless it's a hobby project. The job of languages, imo, is to provide tools/features/syntax for expressing problems, whether their implementation is complex or not. Ruby is an incredible language to use, but its implementation is notoriously hairy. That internal complexity is not something that matters to me in the slightest.

I understand the Go team's reluctance to get the user-facing interface wrong, and end up with something like type-erasure in Java; that's slightly connected with implementation complexity, but saying "it's complex to implement and specify" doesn't seem enough to me.

[edit: made it clearer that this is my thought on the job of languages and not some universal truth]

I actually have a different view. One of the things I love about go is it's a simple language, and I can hold the whole language spec in my head while I'm programming.

A generics implementation can't sacrifice the simplicity of the language, or make it any harder to read go code.

    I can hold the whole language spec in my head while I'm programming

People love to say this about Go, but it's not something that, like, actually matters (and I doubt it's literally true). A language can be reasonably understandable such that you can effectively and productively program in it without being aggressively simple. Again, to use the case of Ruby, I might not remember every single syntactical construct or handling of every edge case, but the language is reasonably understandable such that I can write programs without constantly asking "what was the syntax for that?" or "how do I express this?" As a counter-example, I think the complexity of C++ is not just limited to its implementation, and leaks out to its interface.

    ...sacrifice the simplicity of the language, or make it any harder to read go code

These are two separate concerns which, while somewhat related, are not directly correlated. A simple language can make it more obvious which syntactical constructs are being used and what literal operations are being performed, but there are many more dimensions to reading code than just those.

lisp and smalltalk both manage this while allowing sophisticated abstractions.

I can hold the entire spec to brainfuck in my head, but it doesn't make it any easier to write.

> It should be noted that "takes up a significant part of the language spec, compiler, and VM" isn't a meaningful reason to exclude something from a language, unless it's a hobby project.

If we assume complexity ~= "takes up a significant part of the language spec, compiler, and VM" then I think it's an excellent reason not to include something! Somebody has to maintain this stuff and making it complicated makes that hard, which in turn means less time to spend on things like tooling, performance improvements and documentation which then makes our lives as users of the language harder.

Of course there is a trade-off here but I think, in general, the go team manage to strike a nice balance.

Right, but the entire point of my comment was that "takes up a significant part of the language spec, compiler, and VM" is not a good approximation of complexity. It can be related, but it is not necessarily true that something with a complex implementation has a complex interface.

I think we are talking past each other a bit, as I completely agree with

> it is not necessarily true that something with a complex implementation has a complex interface.

In turn, my point is that as a language implementer you only have so much time available to work on the language and surrounding ecosystem. If your time is spent dealing with a complex spec, compiler and VM then you have less time to spend on the rest of the ecosystem. I think go has shown that spending tim on the surrounding ecosystem can be very valuable (e.g. go fmt, go vet and more recently go fuzz).

Ah, I understand now. That's a fair point! I agree that the excellent Go tooling is one of its strengths.

It was due to the careful and deliberate nature of the Go team, and the backward compatibility guarantee. It took years for the group to put together a proposal with minimal changes to the runtime and core libraries, and this implementation in 1.18 will be limited in scope to only add the feature, waiting for future versions to update other core libraries to adapt generics in a backward-compatible way.

Is there a source for that?

I ask because instances I read from the team were in the direction of: "We will gather enough use cases to decide on the matter".

While the GP was a bit...harsh, the main reason people have that view is generics, as a problem space, were solved. Java's way was published years ago. As was .NET's. Other languages exist which have some form generics. The argument of "gather enough use cases to decide on the matter" feels like a punt given the use cases already exist and were known in the industry for the past 30 years.

The problem space may seem solved, but apparently it's still not as easy as it looks from the outside. You don't have to take my word for it, Cthulhu_ linked a comment by Russ Cox (a major contributor to Go) from a few years ago above: https://news.ycombinator.com/item?id=9622417

> We have spoken to a few true experts in Java generics and each of them has said roughly the same thing: be very careful, it's not as easy as it looks, and you're stuck with all the mistakes you make.

I agree. From my Java experience most people don’t do a lot with them. List<Something> and the like. It makes things like boiler plate easier.

I’m not saying it’s easy to implement. Rather the ideas are there and implementable. Typescript has them and it’s relatively young.

Perhaps. But in hindsight, Go's generics implementation turned different enough to warrant benefit of the doubt in my opinion. A notable difference is that Go interfaces are implicit while C# and Java are explicit and that affects Go generics.

Reply on news.ycombinator.com