undefined | Better HN

0 pointspcwalton12y ago0 comments

> 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.

0 comments

1 comments · 1 top-level

colin_mccabe12y 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.

j / k navigate · click thread line to collapse