1. 12
  1.  

  2. 3

    I’m hoping they someday make more progress towards building shared libraries in Go. I’d be particularly interested if they were compatible with the C calling convention, though there are obvious difficulties implementing that!

    1. 1

      And still, no mention of generics coming to the language at some point.

      1. 6

        This was brought up during the panel discussion later that day.

        TLDR was roughly: They aren’t opposed to it. Just haven’t yet found a proposal that’s idiomatic and makes sense. Contributions welcome.

        1. 5

          I have to confess that I also don’t understand the obsession with Go and generics. If you want a language with generics and a good concurrency story, you can look at Rust or Nimrod. Different languages make different trade-offs on the simplicity/power dynamic; part of Go’s general appeal is that it’s exceedingly simple, and part of Rust’s and Nimrod’s appeal is that they opted for more power.

          1. 2

            See also: http://golang.org/doc/faq#generics

            “This remains an open issue.”

            1. 1

              Do not take this defensively now, but I have heard this lots of times and it has also been mentioned in several Go meetings. I respectfully disagree. It is a non-argument that always gets brought up as the usual Pike defense.

              I do not believe that it is his will to actually resolve this issue within a reasonable amount of time, if at all. I begin to think that In his view, true parametric polymorphism is not something Go should be going after, given that structural sub-typing can serve its goals. We can discuss about the fallacy of this for centuries to no avail. Yes, parametric polymorphism may be more difficult to reason with, but it is also more powerful, expression-wise.

              Also, the question is not about choosing another language like Rust, Nimrod, D - the question is whether it makes sense for a seriously competitive language in 2014 to not possess such a feature and have it thrust upon the language at some indeterminate point. Saying that it is an open issue does not mean anything about it being actually on the roadmap, at all.

              As for contributions being welcome, I do not believe that any contribution without Pike explicitly backing it a priori would have any luck; it will have to come from somebody from the immediate Go design niche given that the criteria of “not liking it and not making sense” can be kind of arbitrary for the eventually interested outsider. Not exactly advisable to contribute under such a constraint, at least for some of us.