5 ms·

>I don't think that anyone is expecting a PL research breakthrough to provide some generics panacea That already happened. In 1976. There is simply no excuse

>I don't think that anyone is expecting a PL research breakthrough to provide some generics panacea That already happened. In 1976. There is simply no excuse for this disingenuous "oh but go is magic and special and can't do it the same way everyone else can" nonsense. If people want that argument to be taken seriously, then they need to start offering actual specific problems with parametric polymorphism as it would apply to go. Not just saying "we're special".

ominous_prime 13y ago
No one is saying generics can't be implemented in go, or that go is "special". Implementing generics requires tradeoffs of some sort -- compile-time and size, runtime efficiency, or language-complexity. The creators didn't want to accept any of these compromises, at least for the initial release of go.
- papsosouid 13y ago
  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.
  - Daishiman 13y ago
    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.
    - deleted 13y ago
      [deleted]
    - azth 13y ago
      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.
      - pkroll 13y ago
        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.
        azth 13y ago
        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.
        papsosouid 13y ago
        >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".
        azth 13y ago
        On the Go mailing list I suppose :) They (the authors) seem that they did not research this issue deeply enough as you mentioned.
      - 13y ago

ominous_prime 13y ago

No one is saying generics can't be implemented in go, or that go is "special". Implementing generics requires tradeoffs of some sort -- compile-time and size, runtime efficiency, or language-complexity. The creators didn't want to accept any of these compromises, at least for the initial release of go.

papsosouid 13y ago
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.
- Daishiman 13y ago
  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.
  - deleted 13y ago
    [deleted]
  - azth 13y ago
    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.
    - pkroll 13y ago
      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.
      - azth 13y ago
        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.
      - papsosouid 13y ago
        >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".
        azth 13y ago
        On the Go mailing list I suppose :) They (the authors) seem that they did not research this issue deeply enough as you mentioned.
    - 13y ago