3 ms·

Go has a kind of generics that also maps cleanly to machine-level generics: interface{}, which is like void* in C. Whereas all the other kinds of generics, I b

Go has a kind of generics that also maps cleanly to machine-level generics: interface{}, which is like void* in C. Whereas all the other kinds of generics, I believe, can't offer this quality. They require a lot of machine code instanciations (like C++'s template system). Or at least, in the case of virtual functions ("dynamic polymorphism" with VTables), they cause more brittle abstraction boundaries. Think how in C++, when definining a class, you need to expose a lot of internal details in the header file -- list all the private member functions and fields, etc. This has lead to the so-called PIMPL idiom which is exactly what you do in Go or C.

pjmlp 8y ago
You don't need to expose any internal details on other languages that make use of generics. Even on C++ this is be eventually a thing of the past, after modules get finally adopted. Using how C++ currently does as argument against generics is a pretty weak argument, given the various ways to implemente them since CLU and ML introduced generic programming into the world.
- jstimpfle 8y ago
  Layouts of separately compiled classes/structs must still be exposed to the compiler. You can't hide layouts away, they are part of the interface. With all the disadvantages that dependencies bring. > Using how C++ currently does as argument against generics is a pretty weak argument, given the various ways to implemente them since CLU and ML introduced generic programming into the world. I would be interested to know how you think the problem of tighter coupling (a.k.a dependencies) is solveable, because I don't see a solution. For example, I'm pretty sure that typeclasses in Haskell are implemented with either of those two approaches I've mentioned depending on the situation. (Maybe it's possible if we require more information for the linker? I haven't thought through this.)
  - pjmlp 8y ago
    Exposed to the compiler doesn't imply exposed to everyone else to see. It is solvable by not sitting in an ivory tower using C++ and Java as the typical examples why Go won't get generics, and instead engage with generics friendly communities.
    - jstimpfle 8y ago
      > Exposed to the compiler doesn't imply exposed to everyone else to see. Personally I care about true, hard dependencies much more than that "exposed for everyone else to see" fluff (the latter being only a subset of the former). Probably that is because I don't do business software, don't work in big teams etc. What really matters to me is reducing hard technical dependencies, and recompile times and ABI compatibility may only be the two biggest reasons. You're probably aware that I program predominantly in C, and "sitting in an ivory tower" is not a word that I would apply to typical C programmers. I wouldn't apply it to Java programmers, either. It's normally a term for the academic world, the world from which languages that focus on type theory originate.
      - pjmlp 8y ago
        I am applying that term to Go developers against generics no matter what. C does provide minimal support for generics since C11, with improvments planned for later standard revisions, as anyone that works predominantly in C should be aware. And yes I am aware that I kind of reversed the meaning of the term, but that is how it feels all the Luddite arguments against generics. Just because there are plenty of old tech languages, which many in the generics crowd have a large experience using, doesn't mean we should keep using such approach at expense of productivity.
        jstimpfle 8y ago
        > I am applying that term to Go developers against generics no matter what. They are actively looking for something that doesn't suck. Aren't they? > C does provide minimal support for generics since C11, with improvments planned for later standard revisions, as anyone that works predominantly in C should be aware. Not sure what was your intention behind that statement. But of course I'm aware of C11 Generics. And they might be nice for a generic min() and max() and similar but other than that honestly I have little use because types are not values and in C, types are not elevated to be much more than simply physical layout. Whenever I've tried to encode meaning in types in any language I've failed spectacularly. Feel free to make Oddintegers and Evenintegers all day long if that's what makes you happy. > And yes I am aware that I kind of reversed the meaning of the term, but that is how it feels all the Luddite arguments against generics. Let's get a life and not spend all of our time raging against people doing different things differently. At Google, I'm sure Go does solve real headaches they have with C++ ((re)compilation issues being only the worst offenders) and Python (performance...). And probably it does so better than any other language can. Because, Google is still primarily an engineering company, not a hipster company, nor a language-obsession company.
ben-schaaf 8y ago
If void pointers are "generics" as you say, then the word is pretty much meaningless. Every language I know of supports that kind of construct and you can usually dump it everywhere as much as you like. Generics specifically refer to the parameterization of types using types. Go doesn't have user defined generics. The only reason in C++ why you need to define all the "internal details" in the header file is because the compiler needs to know the size of things. You can write completely template free code that requires all your classes to be defined in headers or you can litter your code with templates, put pointers everywhere and place all your classes outside of headers. It has nothing to do with generics and everything to do with how the rest of C++ is designed.
- jstimpfle 8y ago
  Thanks for the correction, I shouldn't say "generics". But rather "Go programmers don't have user-defined generics, they use interface{}" or something along those lines. Other than that, I don't think we're in disagreement here.

pjmlp 8y ago

You don't need to expose any internal details on other languages that make use of generics. Even on C++ this is be eventually a thing of the past, after modules get finally adopted. Using how C++ currently does as argument against generics is a pretty weak argument, given the various ways to implemente them since CLU and ML introduced generic programming into the world.

jstimpfle 8y ago
Layouts of separately compiled classes/structs must still be exposed to the compiler. You can't hide layouts away, they are part of the interface. With all the disadvantages that dependencies bring. > Using how C++ currently does as argument against generics is a pretty weak argument, given the various ways to implemente them since CLU and ML introduced generic programming into the world. I would be interested to know how you think the problem of tighter coupling (a.k.a dependencies) is solveable, because I don't see a solution. For example, I'm pretty sure that typeclasses in Haskell are implemented with either of those two approaches I've mentioned depending on the situation. (Maybe it's possible if we require more information for the linker? I haven't thought through this.)
- pjmlp 8y ago
  Exposed to the compiler doesn't imply exposed to everyone else to see. It is solvable by not sitting in an ivory tower using C++ and Java as the typical examples why Go won't get generics, and instead engage with generics friendly communities.
  - jstimpfle 8y ago
    > Exposed to the compiler doesn't imply exposed to everyone else to see. Personally I care about true, hard dependencies much more than that "exposed for everyone else to see" fluff (the latter being only a subset of the former). Probably that is because I don't do business software, don't work in big teams etc. What really matters to me is reducing hard technical dependencies, and recompile times and ABI compatibility may only be the two biggest reasons. You're probably aware that I program predominantly in C, and "sitting in an ivory tower" is not a word that I would apply to typical C programmers. I wouldn't apply it to Java programmers, either. It's normally a term for the academic world, the world from which languages that focus on type theory originate.
    - pjmlp 8y ago
      I am applying that term to Go developers against generics no matter what. C does provide minimal support for generics since C11, with improvments planned for later standard revisions, as anyone that works predominantly in C should be aware. And yes I am aware that I kind of reversed the meaning of the term, but that is how it feels all the Luddite arguments against generics. Just because there are plenty of old tech languages, which many in the generics crowd have a large experience using, doesn't mean we should keep using such approach at expense of productivity.
      - jstimpfle 8y ago
        > I am applying that term to Go developers against generics no matter what. They are actively looking for something that doesn't suck. Aren't they? > C does provide minimal support for generics since C11, with improvments planned for later standard revisions, as anyone that works predominantly in C should be aware. Not sure what was your intention behind that statement. But of course I'm aware of C11 Generics. And they might be nice for a generic min() and max() and similar but other than that honestly I have little use because types are not values and in C, types are not elevated to be much more than simply physical layout. Whenever I've tried to encode meaning in types in any language I've failed spectacularly. Feel free to make Oddintegers and Evenintegers all day long if that's what makes you happy. > And yes I am aware that I kind of reversed the meaning of the term, but that is how it feels all the Luddite arguments against generics. Let's get a life and not spend all of our time raging against people doing different things differently. At Google, I'm sure Go does solve real headaches they have with C++ ((re)compilation issues being only the worst offenders) and Python (performance...). And probably it does so better than any other language can. Because, Google is still primarily an engineering company, not a hipster company, nor a language-obsession company.

ben-schaaf 8y ago

If void pointers are "generics" as you say, then the word is pretty much meaningless. Every language I know of supports that kind of construct and you can usually dump it everywhere as much as you like. Generics specifically refer to the parameterization of types using types. Go doesn't have user defined generics. The only reason in C++ why you need to define all the "internal details" in the header file is because the compiler needs to know the size of things. You can write completely template free code that requires all your classes to be defined in headers or you can litter your code with templates, put pointers everywhere and place all your classes outside of headers. It has nothing to do with generics and everything to do with how the rest of C++ is designed.

jstimpfle 8y ago
Thanks for the correction, I shouldn't say "generics". But rather "Go programmers don't have user-defined generics, they use interface{}" or something along those lines. Other than that, I don't think we're in disagreement here.