4 ms·

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

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.
      - pjmlp 8y ago
        > They are actively looking for something that doesn't suck. Aren't they? It looks more of "we are working on it excuse" to keep people at bay. Rob Pike has done a presentation last year where he stated that he doesn't have anything to do with it and is very sceptical of it being ever added. So WIP is kind of euphemism. > Not sure what was your intention behind that statement. That even languages born before generics are willing to move forward. Google is majorly a Java, Python, C++ shop. Go is usually more outside than internal Google projects. If we reduce Go lack of features to stuff that C doesn't provide, maybe bounds checking, modules and GC aren't required as well. As for complaining, projects like Docker and K8s ensure that those of us that rather not use Go, have to deal with it in some form anyway.

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.
    - pjmlp 8y ago
      > They are actively looking for something that doesn't suck. Aren't they? It looks more of "we are working on it excuse" to keep people at bay. Rob Pike has done a presentation last year where he stated that he doesn't have anything to do with it and is very sceptical of it being ever added. So WIP is kind of euphemism. > Not sure what was your intention behind that statement. That even languages born before generics are willing to move forward. Google is majorly a Java, Python, C++ shop. Go is usually more outside than internal Google projects. If we reduce Go lack of features to stuff that C doesn't provide, maybe bounds checking, modules and GC aren't required as well. As for complaining, projects like Docker and K8s ensure that those of us that rather not use Go, have to deal with it in some form anyway.