Hacker News Reader

Comment by papsosouid | Hacker News Reader

No, it does not require a trade off. That is exactly what I just pointed out. There is no such problem. Parametric polymorphism was solved in 1976. None of the things you mentioned are actual problems, they simply do not exist. Those are invented excuses. If Rob seriously still hasn't bothered to read CS papers from 30+ years ago, that is very unfortunate. But it does not mean the problem wasn't solved, it just means he is unaware of the solution.

View on HN

I'm more willing to trust Rob Pike on his assesment than a random Internet comment from someone who has neither knowledge of Go nor has read the comments on their mailing list.

Appeal to authority. You don't have to trust some random comment on the Internet. Read a little about how generics are implemented in other languages today, and you will be able to see the points the commenter is making.

Quick searches turn up slow compile times as a definite issue with generics. Which means papsosouid's premise is wrong: there IS an issue, and it's one of the ones the Go team considers important. EDIT: read name wrong.

It has been claimed by the D people that D compiles faster than Go. D has a very powerful generic/template system -- even more powerful than C++. Yet, they seem to have solved the compile speed problem, while preserving runtime types (it is a systems language after all).

As I mentioned in another comment in this thread, I have a feeling that the issue with generics in Go is how some language features interact with each other (and not in a good way). Mainly interfaces and object composition. I think this is a good indication that the authors were not aware of several developments in language design at the time of making Go. Not everything is a tradeoff all the time. Certain problems have been solved.

>Quick searches turn up slow compile times as a definite issue with generics

Where? I can find nothing of the sort. And given that we have proof otherwise (compare D to go for example) it seems likely that you are choosing to interpret "some languages made their compilers slower" with "parametric polymorphism must make a compiler slower".

On the Go mailing list I suppose :) They (the authors) seem that they did not research this issue deeply enough as you mentioned.

An appeal to authority is not an argumentative fallacy if the authority is, umm, actually qualified to talk about whatever they're saying. There are at most a couple dozen people more qualified and able to talk about the upsides and downsides of programming languages who, moreover, have seen them in action in the course of several decades of computing history (much of which was directly due to this man's actions).

Really, if you have a language, compiler, and operating systems designer of the caliber of Rob Pike saying that generics introduce a lot of issues, I'm going to need some damned good evidence to the contrary.

Yes, it is still a fallacy. If you have an argument, you can make it without trying to rely on "famous person X agrees". And you seem to be confused about who Rob Pike is. He simply worked at bell labs. After everything important had already happened. He had nothing to do with the creation of unix or C, he just gets lumped in with them because he was at bell labs after the fact.

From Wikipedia:

"He also co-developed the Blit graphical terminal for Unix; before that he wrote the first window system for Unix in 1981. Pike is the sole inventor named in AT&T's US patent 4,555,775 or "backing store patent" that is part of the X graphic system protocol and one of the first software patents. [1]

Over the years Pike has written many text editors; sam and acme are the most well known and are still in active use and development.

Pike, with Brian Kernighan, is the co-author of The Practice of Programming and The Unix Programming Environment. With Ken Thompson he is the co-creator of UTF-8. Pike also developed lesser systems such as the vismon program for displaying images of faces of email authors."

Yeah, some amateur engineering right there. My point still stands; heuristically I have every reason to believe an extremely competent arquitect and designer who is involved in good faith on this project over a random commententer who can't be bothered to assess the evidence.

Did you seriously not notice how nothing in your list of accomplishments is even remotely relevant? We're talking about programming language research, and Pike's experience in that area is seriously lacking.

You don't need to believe anyone, that is the whole point. You are trying to turn it into "some guy's opinion vs the glorious and all-knowing rob's opinion". It is not a question of opinion, it is one of fact. Again, this problem was solved in 1976. ML is very old. Go read the papers on parametric polymorphism.

It seems to me that Pike and gang are mainly coming from a C background. They loathe C++ and Java. Take a look at the SPLASH talk linked in another comment here, and see how the "pain points" mentioned either apply mainly to C and C++ (dependency issues, build times in the case of the latter), or are independent of the language in general (like poor documentation). Then at least 4 sections on that page are just related to dependencies and build times (about 1/3rd of the entire article).

No one is denying that C and C++ have many problems. At the same time though, many of those problems have been solved in other languages (both older and newer than C++).

Reply on news.ycombinator.com