5 ms·

Guess what: they did. https://news.ycombinator.com/item?id=8756683 https://news.ycombinator.com/item?id=8756683 They just weren't ready to make any of the sig

Guess what: they did. https://news.ycombinator.com/item?id=8756683 https://news.ycombinator.com/item?id=8756683 They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them. Whether that's a good outcome, I'm not fully sure - but there's definitely a lot of research in that area.

masklinn 9y ago
> Guess what: they did. Yeah as pointed out in that very thread by pjmlp: As usual, it lacks discussion about generics in: Eiffel Ada Modula-3 D MLton .NET Rust Haskell OCaml Sather BETA CLU Oh wait, they're pointing out that none of these is even remotely being discussed in the article hinting that they did not, in fact, and much prefer taking down strawmen they built from some sort of daguerreotypes of Java and C++. > They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them. Ah yes, the ever so convenient but never actually clarified "tradeoffs", which only ever happen for generics but oddly enough apparently don't happen for any other feature. > there's definitely a lot of research in that area. That there is, would be nice if Go's designers ever bothered actually using it.
pcwalton 9y ago
The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}). The problem with saying "well, this is a tradeoff and both sides have downsides, so we won't do anything" is that the tradeoff still exists—it's just something that manually has to be done by the programmer instead of something that the compiler can do. In Go, the monomorphization approach is done with code duplication (either manually or with go generate), while the boxing approach is done with interface{}. Adding generics to the language just automates one or both of the approaches. The idea that the monomorphization/boxing tradeoff can be dodged by not having generics in the language is a fallacy. In Go, today, you as a programmer already have to decide which side of the tradeoff you want every time you write something that could be generic. It's just that the compiler doesn't help you at all.
- masklinn 9y ago
  > The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}). And even that is not the whole story, just because you reify generics does not mean you have to monomorphise everything, Microsoft's C# compiler only monomorphises value types. Also Go may box in other contexts than interfaces depending on escape analysis (according to https://golang.org/doc/faq#stack_or_heap https://golang.org/doc/faq#stack_or_heap).
  - slrz 9y ago
    The FAQ entry does not state that the Go compiler boxes escaping variables (it doesn't, AFAICT). How did you arrive at that conclusion?
- willtim 9y ago
  In Haskell (and I believe Scala), one can use pragma hints to specify to the compiler when to specialise, if performance becomes a problem. So I don't see this as an argument against parametric polymorphism.
- vram22 9y ago
  >monomorphization Does that mean writing a separate version of an algorithm for each type or types that you want it to handle? Like a sort for ints, a sort for floats, etc., even if the logic is otherwise the same (or almost)? Not a PL design or theory expert, just interested.
  - pcwalton 9y ago
    Yes, it means specializing the code and generating a separate version of the function for each type it is instantiated with.
    - vram22 9y ago
      Got it, thanks.
- 9y ago

masklinn 9y ago

> Guess what: they did. Yeah as pointed out in that very thread by pjmlp: As usual, it lacks discussion about generics in: Eiffel Ada Modula-3 D MLton .NET Rust Haskell OCaml Sather BETA CLU Oh wait, they're pointing out that none of these is even remotely being discussed in the article hinting that they did not, in fact, and much prefer taking down strawmen they built from some sort of daguerreotypes of Java and C++. > They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them. Ah yes, the ever so convenient but never actually clarified "tradeoffs", which only ever happen for generics but oddly enough apparently don't happen for any other feature. > there's definitely a lot of research in that area. That there is, would be nice if Go's designers ever bothered actually using it.

pcwalton 9y ago

The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}). The problem with saying "well, this is a tradeoff and both sides have downsides, so we won't do anything" is that the tradeoff still exists—it's just something that manually has to be done by the programmer instead of something that the compiler can do. In Go, the monomorphization approach is done with code duplication (either manually or with go generate), while the boxing approach is done with interface{}. Adding generics to the language just automates one or both of the approaches. The idea that the monomorphization/boxing tradeoff can be dodged by not having generics in the language is a fallacy. In Go, today, you as a programmer already have to decide which side of the tradeoff you want every time you write something that could be generic. It's just that the compiler doesn't help you at all.

masklinn 9y ago
> The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}). And even that is not the whole story, just because you reify generics does not mean you have to monomorphise everything, Microsoft's C# compiler only monomorphises value types. Also Go may box in other contexts than interfaces depending on escape analysis (according to https://golang.org/doc/faq#stack_or_heap https://golang.org/doc/faq#stack_or_heap).
- slrz 9y ago
  The FAQ entry does not state that the Go compiler boxes escaping variables (it doesn't, AFAICT). How did you arrive at that conclusion?
willtim 9y ago
In Haskell (and I believe Scala), one can use pragma hints to specify to the compiler when to specialise, if performance becomes a problem. So I don't see this as an argument against parametric polymorphism.
vram22 9y ago
>monomorphization Does that mean writing a separate version of an algorithm for each type or types that you want it to handle? Like a sort for ints, a sort for floats, etc., even if the logic is otherwise the same (or almost)? Not a PL design or theory expert, just interested.
- pcwalton 9y ago
  Yes, it means specializing the code and generating a separate version of the function for each type it is instantiated with.
  - vram22 9y ago
    Got it, thanks.
9y ago