5 ms·

>But there is equally no question that adding these features to Go would make it more complex. [...] I have no doubt that adding templated types to Go will make

by jasode 9y ago

>But there is equally no question that adding these features to Go would make it more complex. [...] I have no doubt that adding templated types to Go will make it a more complicated language, I don't know if adding generics to Golang is the right thing to do but I don't agree with how Cheney has framed it. I wish programmers would use a more precise mental framework about "simplicity/complexity". It's not important if generics make the "language specification" more complex. What's really more important is if it makes the real-world language usage more complex. What matters is the sum of total complexity: the language spec + adhoc idioms/patterns/conventions/workarounds used in actual codebases. As an example, if you make a super simple language like Javascript in 1995 with hardly any features, what you eventually end up with is complexity in npm with dozens of modules for things like leftpad(). Or you can insist that "prototypes are simpler than OO" but you actually end up with a dozen OO-simulation libraries with different syntax out in the wild. Instead of the overall JS landscape being simpler, it is more complex. This does not mean you must put everything language feature including the kitchen sink into the language. The lesson learned from history is to talk about about simplicity/complexity in a more holistic way.

munificent 9y ago
This is exactly Larry Wall's point when he talks about the "waterbed theory": https://en.wikipedia.org/wiki/Waterbed_theory https://en.wikipedia.org/wiki/Waterbed_theory Users don't often have the luxury of discarding essential complexity in the problem their trying to solve. So, if you don't give them the right tools to tackle that in your language, that doesn't mean they no longer need those tools. It just means they have to build them themselves first.
grok2 9y ago
I think the author was actually referring to the fact that it makes the written software using Go more complex to understand and maintain. Quoting: "...efforts to add templated types and immutability to the language would unlock the ability to write more complex, less readable software. Indeed, the addition of these features would have a knock on effect that would profoundly alter the way error handling, collections, and concurrency are implemented."
- i_don_t_know 9y ago
  It's not clear to me how templated types and immutability inevitably lead to more complex and less readable software. Can you or someone else explain?
  - catnaroek 9y ago
    Templates have a very complex semantics, because they are checked at instantiation time and can be specialized anywhere. Fortunately, parametric polymorphism and templates have nothing to do with each other. :-)
  - grok2 9y ago
    I think it's perhaps a reference to the original intent of Go at Google. They want new joinees to be quickly productive and also be able to write problem free software (and maybe maintain a lot of old software in addition to writing new software). Having more advanced language features is perhaps not conducive to this. Features like templates do take a bit more effort to grok and also take a bit more effort to understand the flow of code when maintaining software.
    - deleted 9y ago
      [deleted]
  - taeric 9y ago
    Anecdotally, there seems to be a giant rush to get everything covered in generics when people first start learning them. So, what could have been a short section of code that did its job well, is now a larger portion of code that doesn't quite do what anyone wants and you can find yourself just doing a dance with the generic types. I do not know of any studies that explore this concept at large. I would be interested in them.
  - rst 9y ago
    Well, you've got two choices about how you want usage of user-implemented generic container types to look: 1) there are no parameters on the container types, every usage involves a cast to or from 'void*', 'interface{}', or the equivalent, and usage is effectively not type-checked. 2) there are parameters on the container types, subsequent usage isn't cluttered up with uninformative type-casts, and the types get checked by the compiler. These lead to the same code at runtime (or can, in a Java-style implementation of generics); however, the Go maintainers seem to act as if the first is more maintainable and less error-prone. That seems ... odd, to some of us. (There are other possible implementations of generics, of course. In fact, another post by the same author, [1], lists "everything is boxed" as a bad outcome that he'd like to avoid, in favor of specialized implementations for containers of, say, characters. But scenario 1, the Go status quo, effectively requires that everything be boxed when using a generic container type written the only way the language allows you to write them. Scenario 2 at least potentially gives the compiler other options. But the Go status quo doesn't avoid the "everything is boxed" bad outcome. Instead it mandates it -- with additional compile-time clutter.) [1] https://research.swtch.com/generic https://research.swtch.com/generic
deleted 9y ago
[deleted]
xbpx 9y ago
Cheney is also speaking to a camp who have argued against generics in Go using various definitions of simplicity and complexity. Rather than getting into the weeds and highlighting differences in opinion about precise definitions Cheney seems to be acknowledging the validity of the positions of the other side _on their own terms_. This is how compromises are built and IMO a good step for the Generics in Go camp.
toprerules 9y ago
But by pushing complexity into third parties, the vast majority can benifit from a smaller spec and less cognitive load. It's a trade off for sure, but I think as a language designer you have to be careful not to let the 1% convince you that the 99% needs x feature. There are tons of existing Go projects that are working just fine as is. How many of them really need more than what exists already?
- KirinDave 9y ago
  A formulation of this argument has been used since the 1970s and it keeps being proven wrong over and over as progressively people realize the ML and Common Lisp folks were right. Those features are not bullshit invented to make a mathematician happy, they're features that make code safer, more concise, easier to reason about, and easier for optimizers to turn into performant code. Why is it that folks keep trying to formulate this as "the egghead 1% vs the sane 99%?" Stuff is constantly flowing out of academia and advanced production labs and our industry re-levels to that. It's the way a growing industry is supposed to work. Go is not a good language in a technical sense. It's an expression of Google's business needs. Google's got 0 interest in making rank and file programmers better; they're tuned for revolving door recruiting on a massive scale. For them, their goal is to make programmers who only have domain knowledge and require no training. They're not even that interested in lowering shipped error rates; they have a ton of machinery and a whole legion of SRE folks to help manage deployments when testing is minimal and hand-written. To be clear btw, I am not condemning Google for arriving at this conclusion. Their economics are totally different from everyone else's. Every Big Company(tm) has a unique angle of attack on the training problem. Ironically, google's SRE folks are aggressively in the opposite camp in terms of recruiting and practice because they're the ones who actually have to enable this model of shipping broken code safely. Everything about Go is designed to maximize what Google wants out of mid-experience programmers. It's so weird how non-google people seem to find this state of affairs good, as they almost certainly cannot afford to do it this way.
  - remus 9y ago
    > Everything about Go is designed to maximize what Google wants out of mid-range programmers. It's so weird how non-google people seem to find this state of affairs good. If it let's them build products that serve billions of users in ways that that were completely inconceivable even 30 years ago then maybe it's not such a bad tradeoff. To be clear I'm talking more about the philosophy that produced go, not so much the language itself. Obviously Google is more than go.
stcredzero 9y ago
What matters the sum of total complexity: the language spec + adhoc idioms/patterns/conventions/workarounds used in actual codebases. This is a great one sentence summary of the history of C++. (Would also do for a history of programming.) Any hoary Ruby veteran probably has a story about the misuse of missing_method. (Likely one in which they were the antagonist.) The way that the programming field has shaken out, it turns out that there is a group of programmers who are fine with application programming and using well thought out libraries. However, only a minority of these programmers have the ability to engage in the thinking about other-POV and 2nd/3rd order effects that are needed to make a good library or meta-level tool. (Not to mention the community management skills needed to keep people happy while not giving them absolutely everything they want.) As a relative noob, I was listening to hoary Smalltalk veterans talking about this in the early 2000's. This situation is pretty analogous to the one surrounding crypto, except that the consequences of hubris are somewhat milder. The lesson learned from history is to talk about about simplicity/complexity in a more holistic way. Also from the early 2000's -- The Design Patterns guys were often saying that design patterns and other kinds of common incantations were often symptoms of deficiencies in programming language design.
- bcbrown 9y ago
  > The Design Patterns guys were often saying that design patterns and other kinds of common incantations were often symptoms of deficiencies in programming language design. When I reread the GoF book a few years ago, I was struck by the number of patterns that are just built-in to modern languages.
  - rrobukef 9y ago
    Most of the behavioural patterns are eased by fp techniques like lambdas+currying and adt/pattern matching (visitors are well known losers). The structural patterns are however much more a pain in fp while they feel natural in oo. Facades and decorators need type hiding that's only nice(r) with existential types. The creational patterns are a mixed bag. Builder, singleton fit with fp, Abstract Factory fits with oo and factory methods with both. What do you think? How are the oo patterns improved by other techniques. Though a lot of those patterns are probably for C style oo.
justin66 9y ago
> It's not important if generics make the "language specification" more complex. What's really more important is if it makes the real-world language usage more complex. This is what he was talking about when he mentions "more complex, less readable software." On the other hand, he doesn't mention the language specification once.
- jasode 9y ago
  >This is what he was talking about when he mentions "more complex, less readable software." You're making a facile argument without realizing it. For example, when you allow the ability to parameterize a thing, it can make the source code a little "less readable" while simultaneously reducing overall cognitive load. Generics is the ability to parameterize _types_. As comparison, the language feature we are all familiar with is functions which allow us to parameterize _values_. Illustration of abstraction over _values_: This is more readable (using technique of copy & paste): fmt.Println("Hello World") fmt.Println("Hello Jane") The is less readable: func greeting(x string) (string) { return "Hello " + x } func main() { fmt.Println(greeting("World")) fmt.Println(greeting("Jane")) } Programmers may not think the function with passing parameters isn't less readable (because they are used to it) but it actually is. An extra layer of indirection will make the source text somewhat less readable but it's worth it if the net gain in comprehension, maintainability, correctness, etc is improved. That's what parameterizing values via functions allows: it's simultaneously more complex and also more simple at the same time. It's complex at a superficial level but actually simpler at a deeper level. Programmers have embraced the additional "complexity" of "parameterized values" because it makes the language easier to use. A similar analogy about "parameterizing types" can also be made. >, he doesn't mention the language specification once. Yes, if you do Ctrl+F looking for the exact phrase "language specification", you're not going to find it. However, if you understand the meaning of the quotes I pulled, that _is_ what Cheney is actually talking about.
  - justin66 9y ago
    If you're trying to address the topic of simplicity you're being awfully ironic about it.

by jasode 9y ago

munificent 9y ago

This is exactly Larry Wall's point when he talks about the "waterbed theory": https://en.wikipedia.org/wiki/Waterbed_theory https://en.wikipedia.org/wiki/Waterbed_theory Users don't often have the luxury of discarding essential complexity in the problem their trying to solve. So, if you don't give them the right tools to tackle that in your language, that doesn't mean they no longer need those tools. It just means they have to build them themselves first.

grok2 9y ago

I think the author was actually referring to the fact that it makes the written software using Go more complex to understand and maintain. Quoting: "...efforts to add templated types and immutability to the language would unlock the ability to write more complex, less readable software. Indeed, the addition of these features would have a knock on effect that would profoundly alter the way error handling, collections, and concurrency are implemented."

i_don_t_know 9y ago
It's not clear to me how templated types and immutability inevitably lead to more complex and less readable software. Can you or someone else explain?
- catnaroek 9y ago
  Templates have a very complex semantics, because they are checked at instantiation time and can be specialized anywhere. Fortunately, parametric polymorphism and templates have nothing to do with each other. :-)
- grok2 9y ago
  I think it's perhaps a reference to the original intent of Go at Google. They want new joinees to be quickly productive and also be able to write problem free software (and maybe maintain a lot of old software in addition to writing new software). Having more advanced language features is perhaps not conducive to this. Features like templates do take a bit more effort to grok and also take a bit more effort to understand the flow of code when maintaining software.
  - deleted 9y ago
    [deleted]
- taeric 9y ago
  Anecdotally, there seems to be a giant rush to get everything covered in generics when people first start learning them. So, what could have been a short section of code that did its job well, is now a larger portion of code that doesn't quite do what anyone wants and you can find yourself just doing a dance with the generic types. I do not know of any studies that explore this concept at large. I would be interested in them.
- rst 9y ago
  Well, you've got two choices about how you want usage of user-implemented generic container types to look: 1) there are no parameters on the container types, every usage involves a cast to or from 'void*', 'interface{}', or the equivalent, and usage is effectively not type-checked. 2) there are parameters on the container types, subsequent usage isn't cluttered up with uninformative type-casts, and the types get checked by the compiler. These lead to the same code at runtime (or can, in a Java-style implementation of generics); however, the Go maintainers seem to act as if the first is more maintainable and less error-prone. That seems ... odd, to some of us. (There are other possible implementations of generics, of course. In fact, another post by the same author, [1], lists "everything is boxed" as a bad outcome that he'd like to avoid, in favor of specialized implementations for containers of, say, characters. But scenario 1, the Go status quo, effectively requires that everything be boxed when using a generic container type written the only way the language allows you to write them. Scenario 2 at least potentially gives the compiler other options. But the Go status quo doesn't avoid the "everything is boxed" bad outcome. Instead it mandates it -- with additional compile-time clutter.) [1] https://research.swtch.com/generic https://research.swtch.com/generic

deleted 9y ago

[deleted]

xbpx 9y ago

Cheney is also speaking to a camp who have argued against generics in Go using various definitions of simplicity and complexity. Rather than getting into the weeds and highlighting differences in opinion about precise definitions Cheney seems to be acknowledging the validity of the positions of the other side _on their own terms_. This is how compromises are built and IMO a good step for the Generics in Go camp.

toprerules 9y ago

But by pushing complexity into third parties, the vast majority can benifit from a smaller spec and less cognitive load. It's a trade off for sure, but I think as a language designer you have to be careful not to let the 1% convince you that the 99% needs x feature. There are tons of existing Go projects that are working just fine as is. How many of them really need more than what exists already?

KirinDave 9y ago
A formulation of this argument has been used since the 1970s and it keeps being proven wrong over and over as progressively people realize the ML and Common Lisp folks were right. Those features are not bullshit invented to make a mathematician happy, they're features that make code safer, more concise, easier to reason about, and easier for optimizers to turn into performant code. Why is it that folks keep trying to formulate this as "the egghead 1% vs the sane 99%?" Stuff is constantly flowing out of academia and advanced production labs and our industry re-levels to that. It's the way a growing industry is supposed to work. Go is not a good language in a technical sense. It's an expression of Google's business needs. Google's got 0 interest in making rank and file programmers better; they're tuned for revolving door recruiting on a massive scale. For them, their goal is to make programmers who only have domain knowledge and require no training. They're not even that interested in lowering shipped error rates; they have a ton of machinery and a whole legion of SRE folks to help manage deployments when testing is minimal and hand-written. To be clear btw, I am not condemning Google for arriving at this conclusion. Their economics are totally different from everyone else's. Every Big Company(tm) has a unique angle of attack on the training problem. Ironically, google's SRE folks are aggressively in the opposite camp in terms of recruiting and practice because they're the ones who actually have to enable this model of shipping broken code safely. Everything about Go is designed to maximize what Google wants out of mid-experience programmers. It's so weird how non-google people seem to find this state of affairs good, as they almost certainly cannot afford to do it this way.
- remus 9y ago
  > Everything about Go is designed to maximize what Google wants out of mid-range programmers. It's so weird how non-google people seem to find this state of affairs good. If it let's them build products that serve billions of users in ways that that were completely inconceivable even 30 years ago then maybe it's not such a bad tradeoff. To be clear I'm talking more about the philosophy that produced go, not so much the language itself. Obviously Google is more than go.

stcredzero 9y ago

What matters the sum of total complexity: the language spec + adhoc idioms/patterns/conventions/workarounds used in actual codebases. This is a great one sentence summary of the history of C++. (Would also do for a history of programming.) Any hoary Ruby veteran probably has a story about the misuse of missing_method. (Likely one in which they were the antagonist.) The way that the programming field has shaken out, it turns out that there is a group of programmers who are fine with application programming and using well thought out libraries. However, only a minority of these programmers have the ability to engage in the thinking about other-POV and 2nd/3rd order effects that are needed to make a good library or meta-level tool. (Not to mention the community management skills needed to keep people happy while not giving them absolutely everything they want.) As a relative noob, I was listening to hoary Smalltalk veterans talking about this in the early 2000's. This situation is pretty analogous to the one surrounding crypto, except that the consequences of hubris are somewhat milder. The lesson learned from history is to talk about about simplicity/complexity in a more holistic way. Also from the early 2000's -- The Design Patterns guys were often saying that design patterns and other kinds of common incantations were often symptoms of deficiencies in programming language design.

bcbrown 9y ago
> The Design Patterns guys were often saying that design patterns and other kinds of common incantations were often symptoms of deficiencies in programming language design. When I reread the GoF book a few years ago, I was struck by the number of patterns that are just built-in to modern languages.
- rrobukef 9y ago
  Most of the behavioural patterns are eased by fp techniques like lambdas+currying and adt/pattern matching (visitors are well known losers). The structural patterns are however much more a pain in fp while they feel natural in oo. Facades and decorators need type hiding that's only nice(r) with existential types. The creational patterns are a mixed bag. Builder, singleton fit with fp, Abstract Factory fits with oo and factory methods with both. What do you think? How are the oo patterns improved by other techniques. Though a lot of those patterns are probably for C style oo.

justin66 9y ago

> It's not important if generics make the "language specification" more complex. What's really more important is if it makes the real-world language usage more complex. This is what he was talking about when he mentions "more complex, less readable software." On the other hand, he doesn't mention the language specification once.

jasode 9y ago
>This is what he was talking about when he mentions "more complex, less readable software." You're making a facile argument without realizing it. For example, when you allow the ability to parameterize a thing, it can make the source code a little "less readable" while simultaneously reducing overall cognitive load. Generics is the ability to parameterize _types_. As comparison, the language feature we are all familiar with is functions which allow us to parameterize _values_. Illustration of abstraction over _values_: This is more readable (using technique of copy & paste): fmt.Println("Hello World") fmt.Println("Hello Jane") The is less readable: func greeting(x string) (string) { return "Hello " + x } func main() { fmt.Println(greeting("World")) fmt.Println(greeting("Jane")) } Programmers may not think the function with passing parameters isn't less readable (because they are used to it) but it actually is. An extra layer of indirection will make the source text somewhat less readable but it's worth it if the net gain in comprehension, maintainability, correctness, etc is improved. That's what parameterizing values via functions allows: it's simultaneously more complex and also more simple at the same time. It's complex at a superficial level but actually simpler at a deeper level. Programmers have embraced the additional "complexity" of "parameterized values" because it makes the language easier to use. A similar analogy about "parameterizing types" can also be made. >, he doesn't mention the language specification once. Yes, if you do Ctrl+F looking for the exact phrase "language specification", you're not going to find it. However, if you understand the meaning of the quotes I pulled, that _is_ what Cheney is actually talking about.
- justin66 9y ago
  If you're trying to address the topic of simplicity you're being awfully ironic about it.