4 ms·

You're commenting on a paper by expert programming language theorists describing a design that is both complex and (in some aspects) novel. Almost certainly an

You're commenting on a paper by expert programming language theorists describing a design that is both complex and (in some aspects) novel. Almost certainly an element of getting these people to work on it is Go's existing popularity, it's mentioned in the second sentence of the paper. If I understand you right, you are suggesting that instead of doing what they are doing now, they should have just used an existing design from your list, right from the beginning? Is there any specific design from your list that you think would have been good to use in Go? Or, do you think it would have been better to have a less-capable generics implementation available right away instead of a more-capable one later? For example the one you mention the most (Java) requires code duplication to work with 32 and 64 bit floats. I think even the previous proposals that have been rejected for Go have at least had that ability.

pjmlp 6y ago
Yes, right from the beginning. Java isn't the only language to chose from.
- geodel 6y ago
  Huh, if there are so many languages to choose from then people can choose one of those. Go will die its natural death. Where is the problem?
  - pjmlp 6y ago
    The problem is that like with JavaScript in the browser, some of us do have to put up with Go when dealing with k8s, even if we rather not. Secondly, I also kind of like Go, just see it as lost opportunity to have been with little more than a C like type system, even C has some genericity support in the meantime. And whatever gets out of it, will be rather clunky as proven by late adoption in Java.
- throwaway34241 6y ago
  It’s hard for me to believe that it is as simple as you suggest, considering the large amount of work put in by the Go team already, and the even larger amount of work put in by other programming language implementors to eventually arrive at various (different) design points. Work which often takes many years like C++ concepts. Not to mention the open invitation for concrete proposals on how to add them Go. You might find this post by one of the Go team members interesting: https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417
  - pjmlp 6y ago
    As proven by the lack of progress, that invitation has just political value, it allows posts like yours when these discussions take place. For example, while Valhalla has taken several years so far, OpenJDK team has experimental builds that you can go and play around with value types in Java. Where are the experimental builds for generics support in Go?
    - philosopher1234 6y ago
      This actually exists. There’s a go playground earlier in this thread worth generics support
      - pjmlp 6y ago
        Which apparently hasn't been updated since August, 2019. https://github.com/ccbrown/wasm-go-playground/tree/master/experimental/generics https://github.com/ccbrown/wasm-go-playground/tree/master/ex... So this is the prototype used at the GopherCon talk.
    - throwaway34241 6y ago
      > For example, while Valhalla has taken several years so far, OpenJDK team has experimental builds that you can go and play around with value types in Java. Actually Valhalla is pretty interesting to think about. For what I'm currently working on, the inability to have a list of points without individually heap-allocating each one makes a language much more of a non-starter than the lack of user-defined parameterized types does. Even back when Java was invented, there was plenty of prior art (going back decades) about efficiently representing a list of points in memory. Probably most of its predecessors could do it. Yet Java has lacked this basic ability for 25 years. I even expect that when they eventually implement it it will work similarly to other popular languages, compared to Go which seems to be drawing on more recent developments (like concepts etc) for its generics design. Despite this, I don't accuse the Java team of political machinations every time the topic comes up. Mainly because I don't believe that to be the case. Maybe they've prioritized a critical feature for me lower than I would like, but it seems like a substantial amount of work to implement because (like generics) it interacts with other language features in a complex way and (like generics) once they ship a design they will be stuck keeping backwards compatibility with it basically forever, so they only have one chance to get it right.

pjmlp 6y ago

Yes, right from the beginning. Java isn't the only language to chose from.

geodel 6y ago
Huh, if there are so many languages to choose from then people can choose one of those. Go will die its natural death. Where is the problem?
- pjmlp 6y ago
  The problem is that like with JavaScript in the browser, some of us do have to put up with Go when dealing with k8s, even if we rather not. Secondly, I also kind of like Go, just see it as lost opportunity to have been with little more than a C like type system, even C has some genericity support in the meantime. And whatever gets out of it, will be rather clunky as proven by late adoption in Java.
throwaway34241 6y ago
It’s hard for me to believe that it is as simple as you suggest, considering the large amount of work put in by the Go team already, and the even larger amount of work put in by other programming language implementors to eventually arrive at various (different) design points. Work which often takes many years like C++ concepts. Not to mention the open invitation for concrete proposals on how to add them Go. You might find this post by one of the Go team members interesting: https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417
- pjmlp 6y ago
  As proven by the lack of progress, that invitation has just political value, it allows posts like yours when these discussions take place. For example, while Valhalla has taken several years so far, OpenJDK team has experimental builds that you can go and play around with value types in Java. Where are the experimental builds for generics support in Go?
  - philosopher1234 6y ago
    This actually exists. There’s a go playground earlier in this thread worth generics support
    - pjmlp 6y ago
      Which apparently hasn't been updated since August, 2019. https://github.com/ccbrown/wasm-go-playground/tree/master/experimental/generics https://github.com/ccbrown/wasm-go-playground/tree/master/ex... So this is the prototype used at the GopherCon talk.
  - throwaway34241 6y ago
    > For example, while Valhalla has taken several years so far, OpenJDK team has experimental builds that you can go and play around with value types in Java. Actually Valhalla is pretty interesting to think about. For what I'm currently working on, the inability to have a list of points without individually heap-allocating each one makes a language much more of a non-starter than the lack of user-defined parameterized types does. Even back when Java was invented, there was plenty of prior art (going back decades) about efficiently representing a list of points in memory. Probably most of its predecessors could do it. Yet Java has lacked this basic ability for 25 years. I even expect that when they eventually implement it it will work similarly to other popular languages, compared to Go which seems to be drawing on more recent developments (like concepts etc) for its generics design. Despite this, I don't accuse the Java team of political machinations every time the topic comes up. Mainly because I don't believe that to be the case. Maybe they've prioritized a critical feature for me lower than I would like, but it seems like a substantial amount of work to implement because (like generics) it interacts with other language features in a complex way and (like generics) once they ship a design they will be stuck keeping backwards compatibility with it basically forever, so they only have one chance to get it right.