12 ms·

The problem is that there is no empirical evidence to support any of the claims. Even looking at generics, the limited studies I've see show that generics make

by jshen 11y ago

The problem is that there is no empirical evidence to support any of the claims. Even looking at generics, the limited studies I've see show that generics make people a little more productive when using a generic library, but far less productive when trying to write a generic library. In short, these are entirely anecdotal and subjective points of view, so after the 1000th person says, "you are stupid, generics are amazing because .... my anecdotes" well eventually you tune it out. Last, there are a ton of languages out there that have generics, richer type systems, etc. Go is trying something different, and given the lack of real empirical data, lots of experimentation is the best thing. Let Go do it's thing, and let the other language do theirs, why demand that all languages need to make the same trade-off on these topics?

sanderjd 11y ago
I agree with a lot of this, but where things get muddy with empirical evidence, is that it implies a certain "default". In this case that can either be something like "generics are useful" or something like "not having generics is useful". I don't think either hypothesis is supported by much of the sort of empirical evidence you're looking for. Basically, I share your sense that this is all anecdotal and subjective, but in reverse: after the 1000th person says, "generics are too complex and not having them is better because … my anecdotes", I eventually tune it out. Experimentation is definitely the right way to go (har!), but that doesn't imply that people should be mum about the results of their personal experiments! Obviously of these are actual scientific experiments, but when people (like the author of the OP) say "I've used Go and here is what I think", they are in essence reporting the findings of an "experiment" with the language. I don't think anybody is demanding that Go make the same trade-off as other languages, they're just documenting their thoughts on the affect of the various trade-offs.
- dkuntz2 11y ago
  At least in the Go community, it doesn't seem like people are ever saying generics as a concept are bad, but that there are very real tradeoffs involved in adding them to Go, and they're the kinds of tradeoffs the language designers and maintainers have decided they don't want to make. I really like how simple Go is, but I also think generics are super useful, and that if Go could implement them in a Go-y way, I would be incredibly excited, and probably use it even more than I currently do. But I'd rather see the language focused on doing what it currently does well, and making sure it keeps doing things well, over seeing it try to throw in a poorly designed generics system like Java.
  - sanderjd 11y ago
    I'm not sure that I've heard the argument that generics as a concept are bad, per se, but I believe I've heard the argument that they aren't very useful. I (again, non-empirically) disagree with that, but I don't know if it is a common belief in the Go community, and I don't disagree with you at all that generics wouldn't fit very well into Go's philosophy and design and probably don't belong in the language. I think that's a shame, but I still like Go a lot. On the other hand, I do think the author is spot on about nils and multiple return types for error handling. Returning a container type that can represent either a successful or error value is simple (arguably, simpler!) and less error prone. It is something I would love to see in the language. (Somewhat ironically, if it were possible to make generic container types, this wouldn't need to be done in the language itself, but could be a library.)
    - dkuntz2 11y ago
      In practice I'm not sure I see where a PotentiallyErorredResponse object that wraps a response and error together is different from returning a response and an error. The advantage of Optional over returning a value or null is partially that it makes the programmer more aware of the fact that they're dealing with something that might be null. The same thing would be true of an Errorable wrapper. I'd argue that Go makes it more explicit by having compile-time errors when you don't deal with potential error responses.
      - sanderjd 11y ago
        The solutions are definitely similar, but the advantage is eliminating the potential for propagation of nil values. > I'd argue that Go makes it more explicit by having compile-time errors when you don't deal with potential error responses. Showing my ignorance: how does this work? Does the Go compiler check that you check the second return value from a method before doing something with the first return value? I thought you could just ignore the error return and pass along the returned value (which might be nil) as you please. If there's compiler support for avoiding nil propagation, that's great! In the case of a container type like I'm suggesting, you get the compile-time checking from the type system – an error return value is not of the same type as the underlying type, so you have to explicitly get the underlying value out. Even if you accidentally propagate the container, you probably have more information than if you propagate a naked nil, because the error information is part of the container that was propagated, rather than a separate value that might be lost.
- jshen 11y ago
  There is no rigor to this blog post. He didn't have two teams build the same project with and without generics or anything like that. The title is "why go is not good" which is drawing a conclusion based on an anecdote. It's the equivalent of walking outside in December, stating that it's cold, then drawing the conclusion that the globe isn't warming.
  - klodolph 11y ago
    Calls for rigor are unproductive, I think. The unfortunate reality is that an experiment with the rigor you want would be prohibitively expensive. The big differences in productivity I suspect are going to be in larger projects over longer periods of time. You also can't figure anything out from small sample sizes, so you would need to take four large teams, split them randomly into two groups of two, and have each time solve the same large problem over a long period of time. Unfortunately, since we can't afford the rigor, we have to make do with anecdotes and less powerful studies.
    - jshen 11y ago
      I agree, but then we shouldn't assert conclusions with the level of certainty expressed in this blog post and many of the comments here.
  - spion 11y ago
    As far as I can tell, conclusions are based on facts about the language as well as other languages. Maps, slices and channels are generics. I'd like to see code in Go written without maps, slices or generics. Go will never implement immutable data structures. Its impossible to write an immutable data structure library without generics. Go will never implement Futures / Tasks / Observables. Its impossible to write Futures / Tasks without generics. Here are some statistics: In Go its impossible to write 90% of the functions listed here: https://lodash.com/docs https://lodash.com/docs - because they take higher order functions, which use generics. The fact that JavaScript has loops that can be used instead, yet this is still the most popular JavaScript library cannot be reconciled otherwise than by acknowledging that generics are generally useful. Its a damn shame that the language has such flaws: the standard library and tooling are superb. And just generics can single-handedly get rid of 80% of the problems of Go (errors can be modelled with a generic Result<T> which forces you to check for error and allows chaining, generics would enable immutable data structures which are much safer for concurrent programming...)
kazinator 11y ago
Developers are also far more productive when using a programming language than when developing a programming language. So let's not have programming languages. The thing is, a million developers can use a generic library, but only one has to develop it. Excuse me now, I'm going to tune out a million boring arguments of the form "higher level languages are amazing ..." and go back to debugging IBM 360 assembly language program.
lobster_johnson 11y ago
The usefulness of generics is easily demonstrated by Go itself — it has generics. It's only available to a bunch of magical functions (new, make, len, append), types ("chan", "map", arrays and slices are all generic types) and keywords ("range"). But it's there, in plain view. Nobody can objectively argue that these aren't useful, or that they could have been implemented in a non-generic way without destroying the language. Wouldn't the utility transfer to the developer's own code? As for "let Go do its thing", I would argue that it already has been done: Plenty of pre-existing languages don't have generics. The lack is always felt, including in Go's direct precursors (such as Modula-2 and Oberon, languages that people later hacked generics onto because their real-world ergonomy as designed by Wirth wasn't great).

by jshen 11y ago

sanderjd 11y ago

I agree with a lot of this, but where things get muddy with empirical evidence, is that it implies a certain "default". In this case that can either be something like "generics are useful" or something like "not having generics is useful". I don't think either hypothesis is supported by much of the sort of empirical evidence you're looking for. Basically, I share your sense that this is all anecdotal and subjective, but in reverse: after the 1000th person says, "generics are too complex and not having them is better because … my anecdotes", I eventually tune it out. Experimentation is definitely the right way to go (har!), but that doesn't imply that people should be mum about the results of their personal experiments! Obviously of these are actual scientific experiments, but when people (like the author of the OP) say "I've used Go and here is what I think", they are in essence reporting the findings of an "experiment" with the language. I don't think anybody is demanding that Go make the same trade-off as other languages, they're just documenting their thoughts on the affect of the various trade-offs.

dkuntz2 11y ago
At least in the Go community, it doesn't seem like people are ever saying generics as a concept are bad, but that there are very real tradeoffs involved in adding them to Go, and they're the kinds of tradeoffs the language designers and maintainers have decided they don't want to make. I really like how simple Go is, but I also think generics are super useful, and that if Go could implement them in a Go-y way, I would be incredibly excited, and probably use it even more than I currently do. But I'd rather see the language focused on doing what it currently does well, and making sure it keeps doing things well, over seeing it try to throw in a poorly designed generics system like Java.
- sanderjd 11y ago
  I'm not sure that I've heard the argument that generics as a concept are bad, per se, but I believe I've heard the argument that they aren't very useful. I (again, non-empirically) disagree with that, but I don't know if it is a common belief in the Go community, and I don't disagree with you at all that generics wouldn't fit very well into Go's philosophy and design and probably don't belong in the language. I think that's a shame, but I still like Go a lot. On the other hand, I do think the author is spot on about nils and multiple return types for error handling. Returning a container type that can represent either a successful or error value is simple (arguably, simpler!) and less error prone. It is something I would love to see in the language. (Somewhat ironically, if it were possible to make generic container types, this wouldn't need to be done in the language itself, but could be a library.)
  - dkuntz2 11y ago
    In practice I'm not sure I see where a PotentiallyErorredResponse object that wraps a response and error together is different from returning a response and an error. The advantage of Optional over returning a value or null is partially that it makes the programmer more aware of the fact that they're dealing with something that might be null. The same thing would be true of an Errorable wrapper. I'd argue that Go makes it more explicit by having compile-time errors when you don't deal with potential error responses.
    - sanderjd 11y ago
      The solutions are definitely similar, but the advantage is eliminating the potential for propagation of nil values. > I'd argue that Go makes it more explicit by having compile-time errors when you don't deal with potential error responses. Showing my ignorance: how does this work? Does the Go compiler check that you check the second return value from a method before doing something with the first return value? I thought you could just ignore the error return and pass along the returned value (which might be nil) as you please. If there's compiler support for avoiding nil propagation, that's great! In the case of a container type like I'm suggesting, you get the compile-time checking from the type system – an error return value is not of the same type as the underlying type, so you have to explicitly get the underlying value out. Even if you accidentally propagate the container, you probably have more information than if you propagate a naked nil, because the error information is part of the container that was propagated, rather than a separate value that might be lost.
jshen 11y ago
There is no rigor to this blog post. He didn't have two teams build the same project with and without generics or anything like that. The title is "why go is not good" which is drawing a conclusion based on an anecdote. It's the equivalent of walking outside in December, stating that it's cold, then drawing the conclusion that the globe isn't warming.
- klodolph 11y ago
  Calls for rigor are unproductive, I think. The unfortunate reality is that an experiment with the rigor you want would be prohibitively expensive. The big differences in productivity I suspect are going to be in larger projects over longer periods of time. You also can't figure anything out from small sample sizes, so you would need to take four large teams, split them randomly into two groups of two, and have each time solve the same large problem over a long period of time. Unfortunately, since we can't afford the rigor, we have to make do with anecdotes and less powerful studies.
  - jshen 11y ago
    I agree, but then we shouldn't assert conclusions with the level of certainty expressed in this blog post and many of the comments here.
- spion 11y ago
  As far as I can tell, conclusions are based on facts about the language as well as other languages. Maps, slices and channels are generics. I'd like to see code in Go written without maps, slices or generics. Go will never implement immutable data structures. Its impossible to write an immutable data structure library without generics. Go will never implement Futures / Tasks / Observables. Its impossible to write Futures / Tasks without generics. Here are some statistics: In Go its impossible to write 90% of the functions listed here: https://lodash.com/docs https://lodash.com/docs - because they take higher order functions, which use generics. The fact that JavaScript has loops that can be used instead, yet this is still the most popular JavaScript library cannot be reconciled otherwise than by acknowledging that generics are generally useful. Its a damn shame that the language has such flaws: the standard library and tooling are superb. And just generics can single-handedly get rid of 80% of the problems of Go (errors can be modelled with a generic Result<T> which forces you to check for error and allows chaining, generics would enable immutable data structures which are much safer for concurrent programming...)

kazinator 11y ago

Developers are also far more productive when using a programming language than when developing a programming language. So let's not have programming languages. The thing is, a million developers can use a generic library, but only one has to develop it. Excuse me now, I'm going to tune out a million boring arguments of the form "higher level languages are amazing ..." and go back to debugging IBM 360 assembly language program.

lobster_johnson 11y ago

The usefulness of generics is easily demonstrated by Go itself — it has generics. It's only available to a bunch of magical functions (new, make, len, append), types ("chan", "map", arrays and slices are all generic types) and keywords ("range"). But it's there, in plain view. Nobody can objectively argue that these aren't useful, or that they could have been implemented in a non-generic way without destroying the language. Wouldn't the utility transfer to the developer's own code? As for "let Go do its thing", I would argue that it already has been done: Plenty of pre-existing languages don't have generics. The lack is always felt, including in Go's direct precursors (such as Modula-2 and Oberon, languages that people later hacked generics onto because their real-world ergonomy as designed by Wirth wasn't great).