3 ms·

The claim was specifically "without generics there would be no point for servo to exist, because it would be too slow". This explanation only limits what kind o

The claim was specifically "without generics there would be no point for servo to exist, because it would be too slow". This explanation only limits what kind of generics you can use for speed, but not why generics in itself (and specifically as a language feature) are a necessity to get the job done. You could get the same performance (or better) by not writing generic code or by using code generation. Don't get me wrong. No one doubts the usefullness of generics (not even the core authors of go. Not even Rob Pike as the biggest advocate against generics in go). Just the necessity. And in this specific case, claimed performance improvements.

pcwalton 11y ago
> You could get the same performance (or better) by not writing generic code or by using code generation. There are two ways to work around not having generics: use virtual dispatch/reflection (what you usually do in Go, with interfaces) or code duplication. Virtual dispatch is a non-starter from a performance point of view, not only because of the virtual call but also because of the heap allocation that's usually required to use it. Reflection is even worse. Manual code duplication makes it extremely annoying to write well-performing code and reduces productivity. Even worse, though, it reduces safety: lots of the generics in Rust use unsafe code under the hood. If you had to manually duplicate all the code, then the amount of unsafe code would explode. (Imagine having to write atomic reference counting from scratch for each and every type that's atomically reference counted!) As for automatic code duplication via a code generator, that is what generics are. It's just that generics are a particularly good implementation of code duplication: they're integrated with the type system so that the compiler will automatically generate the appropriate code for you without having to go through the trouble of using a separate tool. Having to use a separate tool buys you nothing, as everyone has to learn the tool to write performance-sensitive code, and having to manually request generic instantiations instead of having the compiler do it is a huge nuisance, one that would push people toward not using generics at all and going to virtual dispatch—which brings us back to the performance problems.
- Merovius 11y ago
  Thanks for the detailed answer :) First let me say: I agree, with pretty much everything you say. The communication issue is, that you seem to equate "generics" with how generics are implemented in rust. I don't see it that way. To me, generics are a language feature, that has multiple possible implementations, one is specialized code generation, as in rust. I think Russ Cox summarises this better than me [0]. And from that point of view, I was surprised to hear, that people thought they would improve performance. Because in my mind, they probably improve terseness and maybe improve productivity, but not performance, if you can write a generic algorithm as a template and do a search-and-replace for pretty much the same compiled result. I think, these difference in viewpoints was, what made this discussion so more lengthy than need be. And it's important to note (I think) that no one in the world ever doubted the usefullness, of having generics as a language feature (instead of a standalone tool). When gophers say, that rust is overloaden with features, they don't mean useless features, they just mean, that there are a lot of features. Every feature in C++ is usefull. Every feature in python is usefull. But there are just so many of them, which creates a lot of cognitive overhead and always creates the impulse to contemplate "what's the most elegant way to express this", instead of just expressing it and going on to more important things (Mind you, I don't say this is a philosophy that needs to be shared by everyone, but it's the one people have, when they complain about the number of language features in e.g. rust). I think, Gustavo Niemeyer puts this very well [1]. Anyway, I hope you now understand my question better and also understand better, what the philosophy behind go's minimalism is and what people mean, when they complain about too many features :) [0] http://research.swtch.com/generic http://research.swtch.com/generic [1] http://blog.labix.org/2012/06/26/less-is-more-and-is-not-always-straightforward http://blog.labix.org/2012/06/26/less-is-more-and-is-not-alw...
  - kibwen 11y ago
    > you seem to equate "generics" with how generics are > implemented in rust Given that your question was specific to Servo, and given that Rust is largely motivated by Servo, it should come as no surprise that pcwalton's response was specific to the implementation of generics that makes the most sense for use cases like Servo's. > I was surprised to hear, that people thought they > would improve performance. Making the compiler aware of generics makes it easier to collapse duplicate implementations, which can have a cascading effect on reducing binary size and thereby reducing icache pressure.

pcwalton 11y ago

> You could get the same performance (or better) by not writing generic code or by using code generation. There are two ways to work around not having generics: use virtual dispatch/reflection (what you usually do in Go, with interfaces) or code duplication. Virtual dispatch is a non-starter from a performance point of view, not only because of the virtual call but also because of the heap allocation that's usually required to use it. Reflection is even worse. Manual code duplication makes it extremely annoying to write well-performing code and reduces productivity. Even worse, though, it reduces safety: lots of the generics in Rust use unsafe code under the hood. If you had to manually duplicate all the code, then the amount of unsafe code would explode. (Imagine having to write atomic reference counting from scratch for each and every type that's atomically reference counted!) As for automatic code duplication via a code generator, that is what generics are. It's just that generics are a particularly good implementation of code duplication: they're integrated with the type system so that the compiler will automatically generate the appropriate code for you without having to go through the trouble of using a separate tool. Having to use a separate tool buys you nothing, as everyone has to learn the tool to write performance-sensitive code, and having to manually request generic instantiations instead of having the compiler do it is a huge nuisance, one that would push people toward not using generics at all and going to virtual dispatch—which brings us back to the performance problems.

Merovius 11y ago
Thanks for the detailed answer :) First let me say: I agree, with pretty much everything you say. The communication issue is, that you seem to equate "generics" with how generics are implemented in rust. I don't see it that way. To me, generics are a language feature, that has multiple possible implementations, one is specialized code generation, as in rust. I think Russ Cox summarises this better than me [0]. And from that point of view, I was surprised to hear, that people thought they would improve performance. Because in my mind, they probably improve terseness and maybe improve productivity, but not performance, if you can write a generic algorithm as a template and do a search-and-replace for pretty much the same compiled result. I think, these difference in viewpoints was, what made this discussion so more lengthy than need be. And it's important to note (I think) that no one in the world ever doubted the usefullness, of having generics as a language feature (instead of a standalone tool). When gophers say, that rust is overloaden with features, they don't mean useless features, they just mean, that there are a lot of features. Every feature in C++ is usefull. Every feature in python is usefull. But there are just so many of them, which creates a lot of cognitive overhead and always creates the impulse to contemplate "what's the most elegant way to express this", instead of just expressing it and going on to more important things (Mind you, I don't say this is a philosophy that needs to be shared by everyone, but it's the one people have, when they complain about the number of language features in e.g. rust). I think, Gustavo Niemeyer puts this very well [1]. Anyway, I hope you now understand my question better and also understand better, what the philosophy behind go's minimalism is and what people mean, when they complain about too many features :) [0] http://research.swtch.com/generic http://research.swtch.com/generic [1] http://blog.labix.org/2012/06/26/less-is-more-and-is-not-always-straightforward http://blog.labix.org/2012/06/26/less-is-more-and-is-not-alw...
- kibwen 11y ago
  > you seem to equate "generics" with how generics are > implemented in rust Given that your question was specific to Servo, and given that Rust is largely motivated by Servo, it should come as no surprise that pcwalton's response was specific to the implementation of generics that makes the most sense for use cases like Servo's. > I was surprised to hear, that people thought they > would improve performance. Making the compiler aware of generics makes it easier to collapse duplicate implementations, which can have a cascading effect on reducing binary size and thereby reducing icache pressure.