4 ms·

> "You can't ship software in a language without generics!" Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well

> "You can't ship software in a language without generics!" Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code... As you said, you can already have generics using unsafe solutions. Some built-in types have generics. Most people just want this type safety. interface{} does feel like a temporary and clunky solution for people used to generics. > And lastly, one thing that you can't really appreciate without trying Go--the lack of generics/expressiveness and general simplicity of the language largely means everyone writes the same boring, predictable code, which means you can pretty much pick up any project on GitHub or your own code from years ago and understand it almost immediately. I don't get this argument. Why are generics more complicated than other features? Has this hypothesis been tested? I personally find that using generics is way easier and faster than interface{}, Reflection or code generation. Also simpler and less error-prone than features from other languages like inheritance, operator overloading and unbounded coroutines.

jstimpfle 8y ago
> Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code... As a C programmer (which doesn't have generics either) I can't recall the last time where that additional safety was being missed. Whenever I fed the wrong argument in for a void* parameter (which is rare enough), the program crashed on the first try and the problem is obvious. Plus, Go even has runtime type checking to catch this sort of problem with 100% probability at runtime (I think - I'm not a Go programmer). So I don't think there's a valid problem here. Maybe the more serious problem is that people want to be able to quickly say "I want a Fibonacci-Tree<K,V> for types K and V"?
- latronic_notron 8y ago
  > Whenever I fed the wrong argument in for a void* parameter (which is rare enough), the program crashed on the first try and the problem is obvious. Except when it isn't. Except when it crashes in production. I believe this is the kind of situation people are trying to avoid with type safety... > Maybe the more serious problem is that people want to be able to quickly say "I want a Fibonacci-Tree<K,V> for types K and V"? That's uncalled for, isn't it? There's a lot of non-toy problems solved elegantly and pragmatically using generics. I personally enjoy how Entity Framework uses it.
  - jstimpfle 8y ago
    > Except when it isn't. Yes, but by far more important are bounds checks. Go has bounds checks. As a C programmer I don't get to enjoy them (I get to write simpler, non-GCed, object-cruft-free software in exchange). Out of bounds reads and writes consume far far more of my time compared to void pointers. (And even OOB are not that time consuming). > That's uncalled for, isn't it? There's a lot of non-toy problems... Yes, the Fibonacci was a bad example (couldn't use Map because Go has that). It wasn't meant in a mean way.
    - latronic_notron 8y ago
      > Yes, but by far more important are bounds checks. Sure, but I'm failing to see why having other checks isn't important. I mean, generics aren't hard to use... They're way easier to grasp than Channels (a great feature), and easier to use daily than go generate. I dunno.
      - jstimpfle 8y ago
        Many things are important, and most things require making tradeoffs. When a thing that is only a little bit important prevents something else that is more important (albeit more subtle and requiring experience to see), it's probably better not to choose the first thing. Generics are abstract. They lead to bad error messages. They make the language more complex. They require syntactical support as well as special magic under the hood. Look for various resources by Russ Cox and Rob Pike (and maybe other Go designers). For example https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...
        latronic_notron 8y ago
        I'm familiar with that article, and it got me excited for a while, but it's about compiler implementation, and it doesn't really have much to do with the current discussion, other than rationalizing the opposition for the feature. About your other points: nope, generics wouldn't remove simplicity in the language itself. They would mostly legitimize with type-safety certain idioms that are already present in current Golang code. And the terrible error messages of C++ templates are not really a good example. There are much better languages now when it comes to generics. I suggest that maybe you try looking into other legitimate uses of generics? The Fibonacci-Tree<K,V> example you gave earlier is unrealistic, and the other example being thrown around here, STL, is too complex... There are lots of legitimate reasons for someone wanting generics in a language, and nobody is advocating for them out of bad faith, or wishing to kill a nice language with feature bloat :(
j16sdiz 8y ago
Go use a duck typing system, many of the generic use case can be solved using interface elegantly.. For the rest... Yes, it is very ugly. But the standard generic does not fit very well with go type system, so.... Luckily, go is very simple. Even ugly bit are not hard to understand.
- latronic_notron 8y ago
  > But the standard generic does not fit very well with go type system, so.... Why not? Generics in Arrays/Maps/Slices fit perfectly in the language, and don't feel weird at all in Go.
  - jstimpfle 8y ago
    > Arrays/Maps/Slices They are widely used data structures and so, in the opinion of the Go creators, justified separate specialized implementations in the Go compiler. In other words, there isn't actually a Generics system in the language (I don't actually know this, correct me if I'm wrong). For various reasons. There are quite a few talks and design docs from Rob Pike and Russ Cox if you look for them.
    - latronic_notron 8y ago
      Nope. They are generics, aka parametric polymorphism. And they fit perfectly within Go. And generics aren't just for abstract data structures, there are other uses as well.
      - jstimpfle 8y ago
        I think you've misunderstood what I said. For example here: https://golang.org/src/go/parser/parser.go https://golang.org/src/go/parser/parser.go you can clearly see how e.g. token.MAP is a special case. func (p *parser) tryIdentOrType() ast.Expr { .... case token.MAP: return p.parseMapType() There is a special-cased function parseMapType() function in the Go parser. This isn't generic at all. I mean even the syntax (as in func foo(bar map[String]int) ...) does not seem to be generic at all. Yes, you can use any type as keys and values. But that's a far cry from an abstract system that lets the user define any parameterizable data type. And that's for good reason: By hardcoding just the most important parameterizable data types, the problems that an abstract system would bring can be avoided.
weberc2 8y ago
> Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code... > As you said, you can already have generics using unsafe solutions. Some built-in types have generics. Most people just want this type safety. > interface{} does feel like a temporary and clunky solution for people used to generics. It's not a strawman; I run into this tired argument too often, so I wanted to call it out to avoid the predictable digression. There is a strong case for generics and I empathize with "`interface{}` is clunky..."; I just want a debate that recognizes the tradeoffs. > I don't get this argument. Why are generics more complicated than other features? Has this hypothesis been tested? I don't think I made the argument that "generics are more complicated than other features". My argument was that Go code is boring and predictable (consistent). It stands to reason that boring, consistent code is easier to read and understand than novel and/or mixed-paradigm code. Generics increase expressiveness, which pretty much by definition means fewer rails to keep code consistent. I'm not arguing that Go's current feature set strikes an optimal balance between expressiveness and consistency for all problems; however, it does do a pretty good job and we should count the costs as well as the gains when considering a new feature.
- latronic_notron 8y ago
  I personally find most implementations of generics to be in the class of "boring and predictable". I agree that C++ template meta programming might be a bit too much for Go (or for any language, for that matter), but generics as they are implemented in C# and Java are pretty cool and simple. IMO, if generics were to be ever added in Go they should just be a simple replacement for some uses of interface{} and code generation. I mean, the complexity is already there... why wouldn't generics simplify those use cases?
  - weberc2 8y ago
    I'm talking about code written in Go, not the implementation of any particular feature. Generics would simplify those cases, but they also remove the rails that keeps Go code pretty consistent relative to Java or C#. For example, in Go, there is no functional-vs-imperative conundrum; it's only imperative. And I appreciate that there are multi-paradigm languages like C# and Java that allow for both (better for experimenting with new patterns and paradigms); however, I also appreciate that there are languages like Go that take a more conservative opinion, and I think this is more practical for software development.
zeveb 8y ago
People always go on about type safety, but in practice it normally doesn't matter. I have an instance of a data structure; I put in items of type Foo; I remove items of type interface{} and immediately cast them to type Foo, and life goes on. Sometimes, I might need to put in items of different types, and then I use a type switch. It's not a big deal, nothing panics, I get on with my life. Yes, there's a class of programs for which this is not the case, and for which I might want some sort of fancier guarantees. But those don't tend to be the sort of programs I write. My hobby projects are in Common Lisp; I used to professionally program in Python and JavaScript (for my sins) — Go is strictly better than those in the static-typing department. Would I like generics? Sure, I can see how they'd be nice. But I remember how templates in C++ turned into something nasty, and I've written Java professionally too: I like how clean & simple Go is. I can write code, then be done with it, and come back a year or two later and not be mystified. It's a decent little language for getting stuff done.
- je42 8y ago
  You should read the typescript threads, where people want types to make their code more bug free.

jstimpfle 8y ago

> Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code... As a C programmer (which doesn't have generics either) I can't recall the last time where that additional safety was being missed. Whenever I fed the wrong argument in for a void* parameter (which is rare enough), the program crashed on the first try and the problem is obvious. Plus, Go even has runtime type checking to catch this sort of problem with 100% probability at runtime (I think - I'm not a Go programmer). So I don't think there's a valid problem here. Maybe the more serious problem is that people want to be able to quickly say "I want a Fibonacci-Tree<K,V> for types K and V"?

latronic_notron 8y ago
> Whenever I fed the wrong argument in for a void* parameter (which is rare enough), the program crashed on the first try and the problem is obvious. Except when it isn't. Except when it crashes in production. I believe this is the kind of situation people are trying to avoid with type safety... > Maybe the more serious problem is that people want to be able to quickly say "I want a Fibonacci-Tree<K,V> for types K and V"? That's uncalled for, isn't it? There's a lot of non-toy problems solved elegantly and pragmatically using generics. I personally enjoy how Entity Framework uses it.
- jstimpfle 8y ago
  > Except when it isn't. Yes, but by far more important are bounds checks. Go has bounds checks. As a C programmer I don't get to enjoy them (I get to write simpler, non-GCed, object-cruft-free software in exchange). Out of bounds reads and writes consume far far more of my time compared to void pointers. (And even OOB are not that time consuming). > That's uncalled for, isn't it? There's a lot of non-toy problems... Yes, the Fibonacci was a bad example (couldn't use Map because Go has that). It wasn't meant in a mean way.
  - latronic_notron 8y ago
    > Yes, but by far more important are bounds checks. Sure, but I'm failing to see why having other checks isn't important. I mean, generics aren't hard to use... They're way easier to grasp than Channels (a great feature), and easier to use daily than go generate. I dunno.
    - jstimpfle 8y ago
      Many things are important, and most things require making tradeoffs. When a thing that is only a little bit important prevents something else that is more important (albeit more subtle and requiring experience to see), it's probably better not to choose the first thing. Generics are abstract. They lead to bad error messages. They make the language more complex. They require syntactical support as well as special magic under the hood. Look for various resources by Russ Cox and Rob Pike (and maybe other Go designers). For example https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...
      - latronic_notron 8y ago
        I'm familiar with that article, and it got me excited for a while, but it's about compiler implementation, and it doesn't really have much to do with the current discussion, other than rationalizing the opposition for the feature. About your other points: nope, generics wouldn't remove simplicity in the language itself. They would mostly legitimize with type-safety certain idioms that are already present in current Golang code. And the terrible error messages of C++ templates are not really a good example. There are much better languages now when it comes to generics. I suggest that maybe you try looking into other legitimate uses of generics? The Fibonacci-Tree<K,V> example you gave earlier is unrealistic, and the other example being thrown around here, STL, is too complex... There are lots of legitimate reasons for someone wanting generics in a language, and nobody is advocating for them out of bad faith, or wishing to kill a nice language with feature bloat :(

j16sdiz 8y ago

Go use a duck typing system, many of the generic use case can be solved using interface elegantly.. For the rest... Yes, it is very ugly. But the standard generic does not fit very well with go type system, so.... Luckily, go is very simple. Even ugly bit are not hard to understand.

latronic_notron 8y ago
> But the standard generic does not fit very well with go type system, so.... Why not? Generics in Arrays/Maps/Slices fit perfectly in the language, and don't feel weird at all in Go.
- jstimpfle 8y ago
  > Arrays/Maps/Slices They are widely used data structures and so, in the opinion of the Go creators, justified separate specialized implementations in the Go compiler. In other words, there isn't actually a Generics system in the language (I don't actually know this, correct me if I'm wrong). For various reasons. There are quite a few talks and design docs from Rob Pike and Russ Cox if you look for them.
  - latronic_notron 8y ago
    Nope. They are generics, aka parametric polymorphism. And they fit perfectly within Go. And generics aren't just for abstract data structures, there are other uses as well.
    - jstimpfle 8y ago
      I think you've misunderstood what I said. For example here: https://golang.org/src/go/parser/parser.go https://golang.org/src/go/parser/parser.go you can clearly see how e.g. token.MAP is a special case. func (p *parser) tryIdentOrType() ast.Expr { .... case token.MAP: return p.parseMapType() There is a special-cased function parseMapType() function in the Go parser. This isn't generic at all. I mean even the syntax (as in func foo(bar map[String]int) ...) does not seem to be generic at all. Yes, you can use any type as keys and values. But that's a far cry from an abstract system that lets the user define any parameterizable data type. And that's for good reason: By hardcoding just the most important parameterizable data types, the problems that an abstract system would bring can be avoided.

weberc2 8y ago

> Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code... > As you said, you can already have generics using unsafe solutions. Some built-in types have generics. Most people just want this type safety. > interface{} does feel like a temporary and clunky solution for people used to generics. It's not a strawman; I run into this tired argument too often, so I wanted to call it out to avoid the predictable digression. There is a strong case for generics and I empathize with "`interface{}` is clunky..."; I just want a debate that recognizes the tradeoffs. > I don't get this argument. Why are generics more complicated than other features? Has this hypothesis been tested? I don't think I made the argument that "generics are more complicated than other features". My argument was that Go code is boring and predictable (consistent). It stands to reason that boring, consistent code is easier to read and understand than novel and/or mixed-paradigm code. Generics increase expressiveness, which pretty much by definition means fewer rails to keep code consistent. I'm not arguing that Go's current feature set strikes an optimal balance between expressiveness and consistency for all problems; however, it does do a pretty good job and we should count the costs as well as the gains when considering a new feature.

latronic_notron 8y ago
I personally find most implementations of generics to be in the class of "boring and predictable". I agree that C++ template meta programming might be a bit too much for Go (or for any language, for that matter), but generics as they are implemented in C# and Java are pretty cool and simple. IMO, if generics were to be ever added in Go they should just be a simple replacement for some uses of interface{} and code generation. I mean, the complexity is already there... why wouldn't generics simplify those use cases?
- weberc2 8y ago
  I'm talking about code written in Go, not the implementation of any particular feature. Generics would simplify those cases, but they also remove the rails that keeps Go code pretty consistent relative to Java or C#. For example, in Go, there is no functional-vs-imperative conundrum; it's only imperative. And I appreciate that there are multi-paradigm languages like C# and Java that allow for both (better for experimenting with new patterns and paradigms); however, I also appreciate that there are languages like Go that take a more conservative opinion, and I think this is more practical for software development.

zeveb 8y ago

People always go on about type safety, but in practice it normally doesn't matter. I have an instance of a data structure; I put in items of type Foo; I remove items of type interface{} and immediately cast them to type Foo, and life goes on. Sometimes, I might need to put in items of different types, and then I use a type switch. It's not a big deal, nothing panics, I get on with my life. Yes, there's a class of programs for which this is not the case, and for which I might want some sort of fancier guarantees. But those don't tend to be the sort of programs I write. My hobby projects are in Common Lisp; I used to professionally program in Python and JavaScript (for my sins) — Go is strictly better than those in the static-typing department. Would I like generics? Sure, I can see how they'd be nice. But I remember how templates in C++ turned into something nasty, and I've written Java professionally too: I like how clean & simple Go is. I can write code, then be done with it, and come back a year or two later and not be mystified. It's a decent little language for getting stuff done.

je42 8y ago
You should read the typescript threads, where people want types to make their code more bug free.