3 ms·

> they also remove the rails that keeps Go code pretty consistent But why? There's nothing in generics that would make Go non-consistent. In fact, there's alre

> they also remove the rails that keeps Go code pretty consistent But why? There's nothing in generics that would make Go non-consistent. In fact, there's already generics in Go in Array/Map/Slice, and they're not inconsistent with the rest of the language at all. > For example, in Go, there is no functional-vs-imperative conundrum; it's only imperative Why would generics break that? Funcional programming and type-safety/polymorphism are orthogonal concepts. IIRC, generics were introduced in Barbara Liskov's CLU language, which is imperative. It sounds to me that most people advocating generics in Go are having a pragmatic/utilitarian approach, while people against it are opposing it from a purely ideological standpoint not grounded in either theory or pragmatism.

weberc2 8y ago
> It sounds to me that most people advocating generics in Go are having a pragmatic/utilitarian approach, while people against it are opposing it from a purely ideological standpoint not grounded in either theory or pragmatism. And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :) Even if I were making a positive assertion like "generics costs more than it gains", that would be a pragmatic viewpoint even if it's incorrect. But I'm not even making that assertion, I'm merely unsure and would like to be persuaded otherwise (and I find people with experience on both sides of the fence to be more credible than those without that experience). > Why would generics break that? Because "generics" as a feature suffices to support multi-paradigm programming. It explodes the solution space, creating many solutions for problems that Go's type system is perfectly capable of dealing with (~97% of the problem space in practice according to my experience) while permitting new solutions that Go's type system must currently punt on (~3%). We should be able to roughly agree on this even if we disagree about the degree to which multiple solutions is a problem relative to the advantage of the additional type safety.
- latronic_notron 8y ago
  > And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :) That's fair! I'm really sorry I typed that, it was completely uncalled for and I wasn't referring to you specifically! > Because "generics" as a feature suffices to support multi-paradigm programming. I don't really agree with that. Despite being widely used in functional languages, they aren't really a "functional" thing, as much as static typing is. In fact, I'd argue that Go already has a feature that is much more important and representative of funcional programming than anything else: higher order functions. [1] With higher order functions (and recursion!) you can implement pretty much anything functional. Generics don't really allow for much more than something like interface{} can already give. The problem is that interface{} comes with both runtime performance and type-safety penalties. Generics could fix that and help programmers arrive at better/safer practices, IMO. My point is: with generics the language could be much simpler and we'd have to rely less on (IMO) complicated/unsafe features like Reflection and interface{}. [1] http://aquaraga.github.io/functional-programming/golang/2016/11/19/golang-interfaces-vs-functions.html http://aquaraga.github.io/functional-programming/golang/2016...
  - weberc2 8y ago
    On a phone, so sorry in advance for terse response. Agreed that the language would be simpler in some sense with generics; I don’t think it would be more readable due to aforementioned increase in expressivity. Interesting point about first class functions, and while I largely agree, the variation in Go code is still small and constrained which is my point. :)
    - yawaramin 8y ago
      You don't find the existing Go code using the built-in generics (arrays, dictionaries, channels) readable? You find that its expressiveness makes it too complex?
      - weberc2 8y ago
        Sorry if I haven’t articulated my position very well: the property I care about is consistency of code throughout the ecosystem which exist due to the constraints such as the absense of user-defined generics. Hopefully that’s a little clearer, and makes it obvious why “a few built in genetics” is fundamentally different than user-defines generics.

weberc2 8y ago

> It sounds to me that most people advocating generics in Go are having a pragmatic/utilitarian approach, while people against it are opposing it from a purely ideological standpoint not grounded in either theory or pragmatism. And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :) Even if I were making a positive assertion like "generics costs more than it gains", that would be a pragmatic viewpoint even if it's incorrect. But I'm not even making that assertion, I'm merely unsure and would like to be persuaded otherwise (and I find people with experience on both sides of the fence to be more credible than those without that experience). > Why would generics break that? Because "generics" as a feature suffices to support multi-paradigm programming. It explodes the solution space, creating many solutions for problems that Go's type system is perfectly capable of dealing with (~97% of the problem space in practice according to my experience) while permitting new solutions that Go's type system must currently punt on (~3%). We should be able to roughly agree on this even if we disagree about the degree to which multiple solutions is a problem relative to the advantage of the additional type safety.

latronic_notron 8y ago
> And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :) That's fair! I'm really sorry I typed that, it was completely uncalled for and I wasn't referring to you specifically! > Because "generics" as a feature suffices to support multi-paradigm programming. I don't really agree with that. Despite being widely used in functional languages, they aren't really a "functional" thing, as much as static typing is. In fact, I'd argue that Go already has a feature that is much more important and representative of funcional programming than anything else: higher order functions. [1] With higher order functions (and recursion!) you can implement pretty much anything functional. Generics don't really allow for much more than something like interface{} can already give. The problem is that interface{} comes with both runtime performance and type-safety penalties. Generics could fix that and help programmers arrive at better/safer practices, IMO. My point is: with generics the language could be much simpler and we'd have to rely less on (IMO) complicated/unsafe features like Reflection and interface{}. [1] http://aquaraga.github.io/functional-programming/golang/2016/11/19/golang-interfaces-vs-functions.html http://aquaraga.github.io/functional-programming/golang/2016...
- weberc2 8y ago
  On a phone, so sorry in advance for terse response. Agreed that the language would be simpler in some sense with generics; I don’t think it would be more readable due to aforementioned increase in expressivity. Interesting point about first class functions, and while I largely agree, the variation in Go code is still small and constrained which is my point. :)
  - yawaramin 8y ago
    You don't find the existing Go code using the built-in generics (arrays, dictionaries, channels) readable? You find that its expressiveness makes it too complex?
    - weberc2 8y ago
      Sorry if I haven’t articulated my position very well: the property I care about is consistency of code throughout the ecosystem which exist due to the constraints such as the absense of user-defined generics. Hopefully that’s a little clearer, and makes it obvious why “a few built in genetics” is fundamentally different than user-defines generics.