3 ms·

Maybe. Certainly if releasing without them means they're going to be stuck with a half-assed Javaesque implementation later. On the other hand, generics can com

Maybe. Certainly if releasing without them means they're going to be stuck with a half-assed Javaesque implementation later. On the other hand, generics can complicate a language implementation considerably.

ootachi 15y ago
From an implementation perspective, generics aren't that bad. For an ahead-of-time-compiled language, you either need a uniform value representation (like ML/Java) or a monomorphization pass (like C++). The former corresponds to what Go has today if you simulate generics with interfaces. The latter corresponds to what Go has today if you simulate generics by duplicating your code (for example, if you wrote an IntTree to operate on ints, a StringTree to operate on strings, and so on). They do complicate the typechecker a little bit, largely due to the interaction with subtyping (which Go has via interfaces, I believe). You probably want definition-site variance, not use-site variance like Java, to keep things simple. Also remember that parameterized types must be invariant, not covariant, in the presence of mutability. (Additionally, if you have subtyping for function types, remember that the arguments are contravariant -- Go probably doesn't care about this, though.) None of this stuff is that complicated, though -- it's all pretty straightforward at this point. There's no reason to fear generics. Moreover, as noted above, all of the workarounds end up duplicating effort that the compiler could have done for you. If you use interfaces, you pay the tax of boxing. If you use code duplication, you pay the cost of increased compile times and increased binary size. Nothing is gained from not having generics, except maybe a simpler type system.
densh 15y ago
Java's top priority is to never, ever break anything. It has to be both binary and source compatible. That's a major reason why generics in Java are so broken. They couldn't change syntax to make it nicer and they couldn't substantially change jvm to make it generic-friendly. Which leads us to type erasure and weak integration of generics into the language. Go has quite a different opinion on this question -- we'd rather break things but make a tool (gofix) to automatically fix all your source code. Also Go doesn't aim at binary compatibility at the moment as compilation time is _extremely_ fast and there are no shared library support yet. Most likely they'll be more conservative with Go becoming stable and getting 1.0 release but that doesn't prevent them to break things for 2.0 if that's needed.
- kristianp 15y ago
  Note that, at the moment it looks like Go will never have shared library support. It seems to not be required and I think there's a conflict of interest with the complexity of (or lack of developer resources for) the fast linker Go uses.

ootachi 15y ago

From an implementation perspective, generics aren't that bad. For an ahead-of-time-compiled language, you either need a uniform value representation (like ML/Java) or a monomorphization pass (like C++). The former corresponds to what Go has today if you simulate generics with interfaces. The latter corresponds to what Go has today if you simulate generics by duplicating your code (for example, if you wrote an IntTree to operate on ints, a StringTree to operate on strings, and so on). They do complicate the typechecker a little bit, largely due to the interaction with subtyping (which Go has via interfaces, I believe). You probably want definition-site variance, not use-site variance like Java, to keep things simple. Also remember that parameterized types must be invariant, not covariant, in the presence of mutability. (Additionally, if you have subtyping for function types, remember that the arguments are contravariant -- Go probably doesn't care about this, though.) None of this stuff is that complicated, though -- it's all pretty straightforward at this point. There's no reason to fear generics. Moreover, as noted above, all of the workarounds end up duplicating effort that the compiler could have done for you. If you use interfaces, you pay the tax of boxing. If you use code duplication, you pay the cost of increased compile times and increased binary size. Nothing is gained from not having generics, except maybe a simpler type system.

densh 15y ago

Java's top priority is to never, ever break anything. It has to be both binary and source compatible. That's a major reason why generics in Java are so broken. They couldn't change syntax to make it nicer and they couldn't substantially change jvm to make it generic-friendly. Which leads us to type erasure and weak integration of generics into the language. Go has quite a different opinion on this question -- we'd rather break things but make a tool (gofix) to automatically fix all your source code. Also Go doesn't aim at binary compatibility at the moment as compilation time is _extremely_ fast and there are no shared library support yet. Most likely they'll be more conservative with Go becoming stable and getting 1.0 release but that doesn't prevent them to break things for 2.0 if that's needed.

kristianp 15y ago
Note that, at the moment it looks like Go will never have shared library support. It seems to not be required and I think there's a conflict of interest with the complexity of (or lack of developer resources for) the fast linker Go uses.