4 ms·

With the right implementation debugging generics wont be hard. It doesn't have to be C++'s version of generics. And I'm not buying the poor programmer understa

by spion 12y ago

With the right implementation debugging generics wont be hard. It doesn't have to be C++'s version of generics. And I'm not buying the poor programmer understanding argument. Generics aren't that complex, they're just parameterized types. The fact that basic language libraries such as maps and slices cannot be implemented without them speak volumes about how fundamental they are when building abstractions. My point is that most of the backpressure against generics seems to stem from perceived added complexity to the compiler and type system, and thats all. But I'm not convinced thats a valid argument. Truth be told, I'm not a language implementer. But I know that fast compilers and runtimes that implement generics exist, so I don't find the whole discussion believable.

burntsushi 12y ago
> But I know that fast compilers and runtimes that implement generics exist, so I don't find the whole discussion believable. Are you arguing that an implementation of generics in a programming language is free? (Whether it be performance or implementation complexity.) Because if not, then you admit there are trade offs. If there are trade offs, then it is conceivable that some circumstances (including programmer tastes) may lead to a valuation that is different from yours. "Performance" of the compiler is a critical goal of the Go project. Could you point out for me an industrial strength compiler that supports a type system of your liking that can match the compilation speed of the Go compiler? (I can't think of one.) Because if not, then I'll have to invoke this: talk is cheap, show me the code.
- gnuvince 12y ago
  D's dmd supports templates and is faster than gc.
  - burntsushi 12y ago
    Is there any evidence for this claim? After a quick Google session, the best I could find was a forum thread 4 years ago claiming that `dmd` was faster than `gc`. Is that still true today?
  - f2f 12y ago
    Not anymore. You're two years out of date
- tomp 12y ago
  > Are you arguing that an implementation of generics in a programming language is free? (Whether it be performance or implementation complexity.) I am. Performance: if you replace all generics with interface{}, you get performance that is at better or equal to current Go code. Implementation complexity: You could add some constraints to generics, for example only interface types can be used as generic parameters, and all uses of variables/methods/functions with generic types need to have generic parameters given. In that case, there's no complexity for code that doesn't use generics. Also, generics could actually be implemented as a preprocessor that would simply insert appropriate casts from/to interface{} at calls to generic methods. Since all variables/functions in Go are declared and have known types, you could of course go further and eliminate most generic parameter annotations.
  - burntsushi 12y ago
    > Performance: if you replace all generics with interface{}, you get performance that is at better or equal to current Go code. That is incorrect. Using `interface{}` incurs a significant performance penalty at runtime because you end up boxing everything. For example, you cannot cast a `[]interface{}` to an arbitrary `[]A`. In other words, no, `interface{}` is not `void*`, sorry. If it was, Go would not be memory safe. (See golang.org for their definition of memory safety. It is strictly superior to a language like C, but e.g., less than a language like Rust.)
    - tomp 12y ago
      What I meant is, "better or equal to current Go code using the current version of polymorphism (which is `interface {}`)". AFAIK it's not possible to write generic Go code without `interface {}` (or, alternatively, duplicating the code for each type).
      - burntsushi 12y ago
        Yes, but the tradeoff Go takes right now is "slow programmers," or "no generics." You are trading that in for "slow programs." This directly implies that generics have some sort of cost structure and are not free. `interface{}` is very rarely used for writing "generic" code precisely because of its lack of type safety and performance implications. If you came up with a way to make it type safe without addressing performance, you've just implemented a generics scheme that will cause programs to be slower than they would be without generics (because people would start using them!).

by spion 12y ago

burntsushi 12y ago

> But I know that fast compilers and runtimes that implement generics exist, so I don't find the whole discussion believable. Are you arguing that an implementation of generics in a programming language is free? (Whether it be performance or implementation complexity.) Because if not, then you admit there are trade offs. If there are trade offs, then it is conceivable that some circumstances (including programmer tastes) may lead to a valuation that is different from yours. "Performance" of the compiler is a critical goal of the Go project. Could you point out for me an industrial strength compiler that supports a type system of your liking that can match the compilation speed of the Go compiler? (I can't think of one.) Because if not, then I'll have to invoke this: talk is cheap, show me the code.

gnuvince 12y ago
D's dmd supports templates and is faster than gc.
- burntsushi 12y ago
  Is there any evidence for this claim? After a quick Google session, the best I could find was a forum thread 4 years ago claiming that `dmd` was faster than `gc`. Is that still true today?
- f2f 12y ago
  Not anymore. You're two years out of date
tomp 12y ago
> Are you arguing that an implementation of generics in a programming language is free? (Whether it be performance or implementation complexity.) I am. Performance: if you replace all generics with interface{}, you get performance that is at better or equal to current Go code. Implementation complexity: You could add some constraints to generics, for example only interface types can be used as generic parameters, and all uses of variables/methods/functions with generic types need to have generic parameters given. In that case, there's no complexity for code that doesn't use generics. Also, generics could actually be implemented as a preprocessor that would simply insert appropriate casts from/to interface{} at calls to generic methods. Since all variables/functions in Go are declared and have known types, you could of course go further and eliminate most generic parameter annotations.
- burntsushi 12y ago
  > Performance: if you replace all generics with interface{}, you get performance that is at better or equal to current Go code. That is incorrect. Using `interface{}` incurs a significant performance penalty at runtime because you end up boxing everything. For example, you cannot cast a `[]interface{}` to an arbitrary `[]A`. In other words, no, `interface{}` is not `void*`, sorry. If it was, Go would not be memory safe. (See golang.org for their definition of memory safety. It is strictly superior to a language like C, but e.g., less than a language like Rust.)
  - tomp 12y ago
    What I meant is, "better or equal to current Go code using the current version of polymorphism (which is `interface {}`)". AFAIK it's not possible to write generic Go code without `interface {}` (or, alternatively, duplicating the code for each type).
    - burntsushi 12y ago
      Yes, but the tradeoff Go takes right now is "slow programmers," or "no generics." You are trading that in for "slow programs." This directly implies that generics have some sort of cost structure and are not free. `interface{}` is very rarely used for writing "generic" code precisely because of its lack of type safety and performance implications. If you came up with a way to make it type safe without addressing performance, you've just implemented a generics scheme that will cause programs to be slower than they would be without generics (because people would start using them!).