4 ms·

> 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,

> 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

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.