4 ms·

FWIW I'm not trying to strawman the argument behind not having features like this. Rob Pike said this in a talk about Go: "The key point here is our programmer

FWIW I'm not trying to strawman the argument behind not having features like this. Rob Pike said this in a talk about Go: "The key point here is our programmers are Googlers [...] They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." I'll concede there's the possibility for some weird tongue-in-cheekness here, but it definitely seems to be the canonical view among gophers that Go's paucity of features is about accessibility for programmers that don't understand them or find them cumbersome to work with. I think this idea that "paucity = good" is so easily abusable that whenever this comes up from gophers I wish they would concede that this is an unhelpful simplification of what they must actually believe. Assembly language has possibly the highest paucity of concepts given it offers no ability to introduce language-level abstractions (other than say conventions about calling, etc.), but Go is nothing like this. The argument can't be that paucity is good as a general condition, its that there are forms of abstraction and programming language features that Gophers find unhelpful or difficult to understand. The problem I have with this when applied to parametric polymorphism, is that Gophers already work with these concepts daily, so it can't be that use of them is complicated. I also have a hard time believing that the ability to define parametric types and functions costs you anything. It's almost always self-evident when to use parametric types or functions, things that are "wrappers" or "collections" probably account for 80% of their use. I also don't think I've ever experienced ambiguity of choice with the feature. For instance I don't think I've ever been in the situation where I had to trade off implementing a generic definition vs. N specialized definitions. The frustration of using Go is actually that I now have to consider the later as a possibility or trade off type safety by using unsafe casting. If there's a place where parametricity truly introduces complexity, I'd love to hear about it from a Gopher instead of a blanket statement about how "programmers don't understand it", "it decreases readability", or "Go is simpler without it".

Jtsummers 10y ago
Ouch. That quote is incredibly unkind to his colleagues. I remember back when Google practically required at least a masters degree for their new hires. Throwing out Georgia Tech grads with 4.0 GPAs and only a bachelors. Guess they don't think so highly of their hires anymore.
- snaky 10y ago
  We are yet to be convinced a degree or GPA have any correlation with an actual abilities related to programming with regard to quality, performance, abstractions, languages, tools or anything. By the way, http://www.deathandtaxesmag.com/200732/google-admits-its-famous-job-interview-questions-were-a-complete-waste-of-time/ http://www.deathandtaxesmag.com/200732/google-admits-its-fam...
stcredzero 10y ago
seems to be the canonical view among gophers that Go's paucity of features is about accessibility for programmers that don't understand them or find them cumbersome to work with Please keep in mind that there are differences at scale. What is "easy to work with" for 1 programmer over a month might not be so for 20 programmers over years. The argument can't be that paucity is good as a general condition, its that there are forms of abstraction and programming language features that Gophers find unhelpful or difficult to understand The argument is that simpler is better at scale. Airplanes can move freely in 3 dimensions, but airliners are constrained to fly in particular ways around busy airports and cross country. I also have a hard time believing that the ability to define parametric types and functions costs you anything. It's almost always self-evident when to use parametric types or functions, things that are "wrappers" or "collections" probably account for 80% of their use. I could see an argument for parametric collections and parametric sorting in Go. Not, however, for wrappers. The frustration of using Go is actually that I now have to consider the later as a possibility or trade off type safety by using unsafe casting. In your experience, what kind of "cost" has there been in unsafe casting to use collections? Even in environments like Smalltalk, where all use of collections amounts to "unsafe casting," I've rarely seen situations where a mistake of this type wasn't found trivially. Does your frustration come from having to abandon the "assured safety" the type system would give you, or does it come from an experience of the costs?
- catnaroek 10y ago
  > The argument is that simpler is better at scale. Parametric polymorphism is simple and well understood. And not exactly new either: it has been understood for some 40 years already. > I could see an argument for parametric collections and parametric sorting in Go. C++'s <algorithm> header is proof that there are lots of algorithms that benefit from being expressed generically, not just sorting. > In your experience, what kind of "cost" has there been in unsafe casting to use collections? Without type safety, there's a disincentive for decomposing things into smaller parts, because the cost of manually verifying that the parts are compatible is greater than the benefits of decoupling them. Would a Go programmer even dream of bootstrapping fancy data structures from simpler ones? > Even in environments like Smalltalk, where all use of collections amounts to "unsafe casting," I've rarely seen situations where a mistake of this type wasn't found trivially. At scale, the law of large numbers says that even improbable events will occur every now and then. Unfortunately, a program with even one bug is still incorrect.

Jtsummers 10y ago

Ouch. That quote is incredibly unkind to his colleagues. I remember back when Google practically required at least a masters degree for their new hires. Throwing out Georgia Tech grads with 4.0 GPAs and only a bachelors. Guess they don't think so highly of their hires anymore.

snaky 10y ago
We are yet to be convinced a degree or GPA have any correlation with an actual abilities related to programming with regard to quality, performance, abstractions, languages, tools or anything. By the way, http://www.deathandtaxesmag.com/200732/google-admits-its-famous-job-interview-questions-were-a-complete-waste-of-time/ http://www.deathandtaxesmag.com/200732/google-admits-its-fam...

stcredzero 10y ago

seems to be the canonical view among gophers that Go's paucity of features is about accessibility for programmers that don't understand them or find them cumbersome to work with Please keep in mind that there are differences at scale. What is "easy to work with" for 1 programmer over a month might not be so for 20 programmers over years. The argument can't be that paucity is good as a general condition, its that there are forms of abstraction and programming language features that Gophers find unhelpful or difficult to understand The argument is that simpler is better at scale. Airplanes can move freely in 3 dimensions, but airliners are constrained to fly in particular ways around busy airports and cross country. I also have a hard time believing that the ability to define parametric types and functions costs you anything. It's almost always self-evident when to use parametric types or functions, things that are "wrappers" or "collections" probably account for 80% of their use. I could see an argument for parametric collections and parametric sorting in Go. Not, however, for wrappers. The frustration of using Go is actually that I now have to consider the later as a possibility or trade off type safety by using unsafe casting. In your experience, what kind of "cost" has there been in unsafe casting to use collections? Even in environments like Smalltalk, where all use of collections amounts to "unsafe casting," I've rarely seen situations where a mistake of this type wasn't found trivially. Does your frustration come from having to abandon the "assured safety" the type system would give you, or does it come from an experience of the costs?

catnaroek 10y ago
> The argument is that simpler is better at scale. Parametric polymorphism is simple and well understood. And not exactly new either: it has been understood for some 40 years already. > I could see an argument for parametric collections and parametric sorting in Go. C++'s <algorithm> header is proof that there are lots of algorithms that benefit from being expressed generically, not just sorting. > In your experience, what kind of "cost" has there been in unsafe casting to use collections? Without type safety, there's a disincentive for decomposing things into smaller parts, because the cost of manually verifying that the parts are compatible is greater than the benefits of decoupling them. Would a Go programmer even dream of bootstrapping fancy data structures from simpler ones? > Even in environments like Smalltalk, where all use of collections amounts to "unsafe casting," I've rarely seen situations where a mistake of this type wasn't found trivially. At scale, the law of large numbers says that even improbable events will occur every now and then. Unfortunately, a program with even one bug is still incorrect.