3 ms·

I think a big part of the issue is that in Java and C++, you really need generics a lot more than in Go. Without templates, you would not have any easy way of

I think a big part of the issue is that in Java and C++, you really need generics a lot more than in Go. Without templates, you would not have any easy way of doing maps and lists in C++. There are no builtin types for those like in Go. The way the type system works in those languages also makes things very difficult if you don't have generics. Think about the sorting example I wrote earlier: https://news.ycombinator.com/item?id=7080562 https://news.ycombinator.com/item?id=7080562 If you were writing it in Java, is sort.Sort an interface or an abstract base class? Well, you can only "extend" one class (single inheritance only), so you would probably want Sort to be a Java interface. That means that you would always have to implement all three functions, not just one as I did, since Java interfaces cannot have default implementations. The comments indicate that most posters didn't even consider the idea that you could reuse the StringSlice functions. That method of easy composition simply doesn't exist in Java. In general, generics get used a lot as a band-aid to avoid multiple inheritance in C++ and Java. You can't (or shouldn't, in C++) have your Foo inherit from both a (non-abstract) Bar and Baz. But you can certainly template on them. In C++, this kind of thing is called "traits" and Alexandrescu wrote a whole book about it. It's also why std::string is actually std::basic_string<char, std::char_traits<char>, std::allocator<char> >. In Go, you don't need all this... you just implement as many interfaces as you like and you're done. So the Java and C++ programmers need time and an open mind to get up to speed. There's also another contingent of programmers that really just wants Go to be like their favorite strongly-typed functional programming language (Haskell, Scheme, SML, etc.) I like to think that these people will eventually give up. After all, nobody comes into every Lisp thread demanding that Lisp grow a type-checker. People have sort of accepted that that is not what Lisp is about and that there are other languages that will give you that if you want. Hopefully much the same will happen for Golang.

pjmlp 13y ago
Java 8 will have interfaces with default implementations. There are a few of optional type checkers for Lisp to choose from.
scott_s 13y ago
It is common in both C++ and Java for a class to implement several interfaces. So, one can accomplish the same kind of genericity in C++ and Java as one can in Go. Both languages still eventually saw enough of a need for a kind of generics to develop one. There is a difference in Go, and that is you don't need to explicitly implement the interface. That is, you don't need to declare that you do. But I am unconvinced that is so different from implementing interfaces in C++ and Java that C++ and Java programmers "need time and an open mind" to understand Go idioms. Don't get me wrong: I think Go is a neat language and culture. I like many aspects of it. And I know the stance the designers of Go have on generics: they would like to do them, but they can't think of a design that they like. And they don't consider it that important, so they've bunted on it. They may do them in the future. But I find it strange when people who are not the designers of the language argue against having them, in any form.
pcwalton 13y ago
> It's also why std::string is actually std::basic_string<char, std::char_traits<char>, std::allocator<char> > Actually, that's not a band-aid. It allows strings to be generic over allocators without suffering the performance penalty of a virtual call on every malloc and free. Go's solution would be to just take the penalty of a virtual call (as interfaces require virtual calls everywhere) and try to make it up with devirtualization optimizations and/or inlining. > After all, nobody comes into every Lisp thread demanding that Lisp grow a type-checker. That's because making a workable type system for Lisp is a very hard problem. By contrast, generics are well known at this point.
- colin_mccabe 13y ago
  It's certainly true that Go doesn't currently support compile-time polymorhpism, and C++ does. In that sense, Go interfaces are not a replacement for C++ templates, as you correctly note. However, compile-time polymorphism is a mixed bag because of how it tends to blow out the icache by generating many copies of similar code. Java does away with it completely, and nobody seems to be protesting. The Linux kernel is written in C, and nobody seems to be protesting that the lack of compile-time polymorphism makes his/her job impossible. Clearly, the decision as to whether to include compile-time polymorphism in a language is something reasonable people can disagree about. With regard to a type system for Lisp: it's been done before. Check out Qi.

pjmlp 13y ago

Java 8 will have interfaces with default implementations. There are a few of optional type checkers for Lisp to choose from.

scott_s 13y ago

It is common in both C++ and Java for a class to implement several interfaces. So, one can accomplish the same kind of genericity in C++ and Java as one can in Go. Both languages still eventually saw enough of a need for a kind of generics to develop one. There is a difference in Go, and that is you don't need to explicitly implement the interface. That is, you don't need to declare that you do. But I am unconvinced that is so different from implementing interfaces in C++ and Java that C++ and Java programmers "need time and an open mind" to understand Go idioms. Don't get me wrong: I think Go is a neat language and culture. I like many aspects of it. And I know the stance the designers of Go have on generics: they would like to do them, but they can't think of a design that they like. And they don't consider it that important, so they've bunted on it. They may do them in the future. But I find it strange when people who are not the designers of the language argue against having them, in any form.

pcwalton 13y ago

> It's also why std::string is actually std::basic_string<char, std::char_traits<char>, std::allocator<char> > Actually, that's not a band-aid. It allows strings to be generic over allocators without suffering the performance penalty of a virtual call on every malloc and free. Go's solution would be to just take the penalty of a virtual call (as interfaces require virtual calls everywhere) and try to make it up with devirtualization optimizations and/or inlining. > After all, nobody comes into every Lisp thread demanding that Lisp grow a type-checker. That's because making a workable type system for Lisp is a very hard problem. By contrast, generics are well known at this point.

colin_mccabe 13y ago
It's certainly true that Go doesn't currently support compile-time polymorhpism, and C++ does. In that sense, Go interfaces are not a replacement for C++ templates, as you correctly note. However, compile-time polymorphism is a mixed bag because of how it tends to blow out the icache by generating many copies of similar code. Java does away with it completely, and nobody seems to be protesting. The Linux kernel is written in C, and nobody seems to be protesting that the lack of compile-time polymorphism makes his/her job impossible. Clearly, the decision as to whether to include compile-time polymorphism in a language is something reasonable people can disagree about. With regard to a type system for Lisp: it's been done before. Check out Qi.