3 ms·

I think the "we're not doing it because it adds complexity in the type system and runtime" was something most developpers have a very hard time understanding, s

by bsaul 7y ago

I think the "we're not doing it because it adds complexity in the type system and runtime" was something most developpers have a very hard time understanding, since generic programming exists in pratically every single PL created since C++. My understanding not just from the FAQ but also from reading conversation in the forums, was that they thought the feature itself had such a high potential of being misused as a crutch for bad designs that they thought not having generics was actually a feature. And to be honest i almost agree 100% with that perception. The problem is that it leads to archaism and copy pasting that make a few lines of codes here and there look just gross (although perfectly understandable).

pjmlp 7y ago
It is even older than C++, CLU, ML had it first during the mid-70s, Ada and Modula-3 got it first in the early 80's, and C++ STL work actually was initially done in Ada.
danieldk 7y ago
I think the "we're not doing it because it adds complexity in the type system and runtime" was something most developpers have a very hard time understanding, since generic programming exists in pratically every single PL created since C++. Plus, history has taught us that retrofitting generics to existing languages with their ecosystems can be difficult and painful (see Java and to some extend C++).
- ryanianian 7y ago
  Java's generics are certainly awkward, and lots of code would look better if generics had been real from v1.0. I'm looking forward to Java's specialized generic impls (e.g. ArrayList<int>) that seem heavily inspired by the route C++ takes of compile-time class-instantiation. But out of curiosity what's difficult/painful about C++'s "retrofitted" generics (templates)? There's a lot to not like about templates, but as far as I know they've remained relatively unchanged and have always been just as difficult and painful (and powerful) as they are now. Are you referring to the decision to make SFINAE a de-facto way to constrain parameters?
  - pjmlp 7y ago
    Concepts I guess, so much pain would have been saved if something like that existed in C++98.
- mook 7y ago
  > Plus, history has taught us that retrofitting generics to existing languages with their ecosystems can be difficult and painful (see Java and to some extend C++). I believe that C# also had retrofitted generics, but the reputation there doesn't seem nearly as bad. But I believe the generic containers there were intentionally not compatible with the original non-generic version.
  - jen20 7y ago
    The major difference is that the CLR is aware of generics rather them being a compiler trick as they are with the JVM. Don Syme (father of F#, who also worked on the implementation of generics in the CLR) did a talk explaining the history and how they almost shipped with erased generics like the JVM. On the other hand, it's been claimed that erased generics have made things easier for implementing other languages on the platform, so there are tradeoffs I guess. Having used both I would take the CLR implementation any day.
    - pjmlp 7y ago
      Same here, but I still have high hopes for Valhalla.
  - pjmlp 7y ago
    Not at all, Microsoft just decided not to delay .NET 1.0 release instead of having them fully implemented. https://mattwarren.org/2018/03/02/How-generics-were-added-to-.NET/ https://mattwarren.org/2018/03/02/How-generics-were-added-to...
wtetzner 7y ago
You can obviously abuse C++ templates, because they are more (or less, depending on how you look at it) than simple generics. However, in what way can parametric polymorphism be misused or be a crutch for bad designs? I can't think of an example that wouldn't be horribly contrived.
- bsaul 7y ago
  Well, parametric polymorphism in the case of go would probably just be a performance optimisation over function taking interface as parameter, right ? i usually see monsters when you combine generics with objects and inheritence, but you're right that since go also doesn't provide those... i think when talking about generics in go we also mean struct accepting generic components. Not just functions
  - wtetzner 7y ago
    Sure, and I still don't really see a problem with it. Yes, it makes the compiler more complex, but I can't think of any ways it could be abused more than the existing language features. And it would make a lot of programs written in Go simpler.
    - bsaul 7y ago
      Because go is very used in data plumbing code, i found that many functions can actually work fine at the byte array level, and that it leads to a better design. It would be very tempting with proper generic support to try to have every function work with the topmost types, just because we assume it provides more type safety. I could imagine a struct representing a "User" byte array, or other atrocities.
- hderms 7y ago
  it's a mystery, especially to anyone who has ever seen JSON handling code in Go, that they would think generics are a crutch for bad design.

by bsaul 7y ago

pjmlp 7y ago

It is even older than C++, CLU, ML had it first during the mid-70s, Ada and Modula-3 got it first in the early 80's, and C++ STL work actually was initially done in Ada.

danieldk 7y ago

I think the "we're not doing it because it adds complexity in the type system and runtime" was something most developpers have a very hard time understanding, since generic programming exists in pratically every single PL created since C++. Plus, history has taught us that retrofitting generics to existing languages with their ecosystems can be difficult and painful (see Java and to some extend C++).

ryanianian 7y ago
Java's generics are certainly awkward, and lots of code would look better if generics had been real from v1.0. I'm looking forward to Java's specialized generic impls (e.g. ArrayList<int>) that seem heavily inspired by the route C++ takes of compile-time class-instantiation. But out of curiosity what's difficult/painful about C++'s "retrofitted" generics (templates)? There's a lot to not like about templates, but as far as I know they've remained relatively unchanged and have always been just as difficult and painful (and powerful) as they are now. Are you referring to the decision to make SFINAE a de-facto way to constrain parameters?
- pjmlp 7y ago
  Concepts I guess, so much pain would have been saved if something like that existed in C++98.
mook 7y ago
> Plus, history has taught us that retrofitting generics to existing languages with their ecosystems can be difficult and painful (see Java and to some extend C++). I believe that C# also had retrofitted generics, but the reputation there doesn't seem nearly as bad. But I believe the generic containers there were intentionally not compatible with the original non-generic version.
- jen20 7y ago
  The major difference is that the CLR is aware of generics rather them being a compiler trick as they are with the JVM. Don Syme (father of F#, who also worked on the implementation of generics in the CLR) did a talk explaining the history and how they almost shipped with erased generics like the JVM. On the other hand, it's been claimed that erased generics have made things easier for implementing other languages on the platform, so there are tradeoffs I guess. Having used both I would take the CLR implementation any day.
  - pjmlp 7y ago
    Same here, but I still have high hopes for Valhalla.
- pjmlp 7y ago
  Not at all, Microsoft just decided not to delay .NET 1.0 release instead of having them fully implemented. https://mattwarren.org/2018/03/02/How-generics-were-added-to-.NET/ https://mattwarren.org/2018/03/02/How-generics-were-added-to...

wtetzner 7y ago

You can obviously abuse C++ templates, because they are more (or less, depending on how you look at it) than simple generics. However, in what way can parametric polymorphism be misused or be a crutch for bad designs? I can't think of an example that wouldn't be horribly contrived.

bsaul 7y ago
Well, parametric polymorphism in the case of go would probably just be a performance optimisation over function taking interface as parameter, right ? i usually see monsters when you combine generics with objects and inheritence, but you're right that since go also doesn't provide those... i think when talking about generics in go we also mean struct accepting generic components. Not just functions
- wtetzner 7y ago
  Sure, and I still don't really see a problem with it. Yes, it makes the compiler more complex, but I can't think of any ways it could be abused more than the existing language features. And it would make a lot of programs written in Go simpler.
  - bsaul 7y ago
    Because go is very used in data plumbing code, i found that many functions can actually work fine at the byte array level, and that it leads to a better design. It would be very tempting with proper generic support to try to have every function work with the topmost types, just because we assume it provides more type safety. I could imagine a struct representing a "User" byte array, or other atrocities.
hderms 7y ago
it's a mystery, especially to anyone who has ever seen JSON handling code in Go, that they would think generics are a crutch for bad design.