5 ms·

The "linage" implies that they aren't aware of it, or at least they weren't when designing the language. Rob Pike is more of a systems guy than a type theorist.

The "linage" implies that they aren't aware of it, or at least they weren't when designing the language. Rob Pike is more of a systems guy than a type theorist. Like most systems guys, they know of how C handles types and how C++ handles types. The concept of Parametric Polymorphism or sum types outside of OOP is most likely something Rob Pike was not familiar with as it's hard to see why sum types were not included in the language. Having IO functions return a tuple of error and value rather then an Option type is not simplicity it's complexity arising from lack of a type primitive. The feature is ugly and very much looks like it was implemented by someone who wasn't aware of a type that can be a Value OR an Error. So instead he implemented a type that can be an Error AND a Value and left it to manual run time checks for the programmer to figure out if an error even occurred. The other thing is that this "tuple" type of error AND value looks like a hack. Tuple types can't be saved to a variable in GO and can only be returned by functions and immediately unrolled into its separate primitive values. It's like Rob knew something was off in this area so he created a temporary concept of a tuple in the return value of a function to make up for it. A consistently designed language wouldn't have a Tuple only returnable by a function call. It seems strange and inconsistent. Additionally, the fact that, in GO, some types can have Nils and other types default to a zero value implies that Rob Knew nulls were bad but didn't know how to completely get rid of the null. I'm thinking that Robs initial notions of sum types and parametric polymorphism is that they can only be implemented via hierarchies of inheritance which in itself has many problems. It makes sense because this is what systems programmers are exposed to (C, C++) as opposed to typed lambda calculus or Haskell. So it's easy to see that Go is the result of Robs awareness of problems with OOP but lack of awareness of the theoretical alternative.

foldr 7y ago
Having the value returned together with the error is convenient for a couple of reasons. First, it's often possible for the function to return a meaningful value even in an error case (e.g., number of bytes read before the error occurred). Second, it's often possible to return a sensible 'null' value together with an error which can be handled correctly without checking the error value. (A map lookup is the obvious example of this.) This simplifies logic in some places. Using sum types for errors in Go wouldn't actually work very well unless you fundamentally changed other aspects of the language. You'd need pattern matching, a whole bunch of generic higher order functions for manipulating option/result types, etc. etc.
- crimsonalucard 7y ago
  >First, it's often possible for the function to return a meaningful value even in an error case Create a type that explicitly stores this information. The return type can hold the (error message and a value) OR (just a value). This type expression is a more accurate description of what's really going on. Whichever way you want to represent the product type it's not isomorphic to the actual intended result that the function should return. A sum type can represent the return value of the sentence below while GO cannot: "A function that returns (a value) OR an (error with a value)" This is the true intention of the function you described. >Second, it's often possible to return a sensible 'null' value together with an error which can be handled correctly without checking the error value. (A map lookup is the obvious example of this.) This simplifies logic in some places. But opens up the possibility of a runtime error if you fail to check for it. Historically there are tons of functions in C, C++ or javascript that use null to represent an error and it is self quoted to be the greatest mistake ever made by the creator of null. No language needs a null. >Using sum types for errors in Go wouldn't actually work very well unless you fundamentally changed other aspects of the language. You'd need pattern matching.... Using product types to represent errors has already changed the nature of GO in a very hacky way. Only Functions in GO can return tuples and the concept of the tuple can never be used anywhere else. You cannot save a variable as a tuple, you cannot pass a tuple as an argument. You can only return a tuple then instantly unroll it. It's an arbitrary hacky feature obviously made to support error values. It would be better to have an arbitrary pattern matching feature... this makes more sense then arbitrary tuples returned from functions. >a whole bunch of generic higher order functions for manipulating option/result types, etc. etc. Actually no you don't. The fact that go functions return tuples with errors, does this mean that higher order functions need to handle tuples? No! not at all. In fact go explicitly eliminates support for this... The tuples in GO need to be unrolled into their constituent types before they can be used in any other function. The same concept can be applied to Option types. You have to unroll the value and explicitly handle either individual type. You do not ever need a higher order function that accepts the Option type as a parameter. Like all languages that have the Option Type/Maybe Monad etc... Any function that returns this type represents a function that is impure that needs to be unrolled first before passing the value down to the functions that do closed and pure calculations. A function that takes an Option type as a parameter is a function that says "I am a function that can only take values from IO" It's very rare for functions to be implemented like this even in languages that have first class support for the sum type and Monads. In haskell I can't recall ever seeing a function that takes the IO monad as a parameter. In haskell and in Rust these values need to be unrolled into their constituent types before they can be used. Please note I am not advocating the inclusion of Monads into GO. Just talking about sum types.
AnimalMuppet 7y ago
He was at the premiere computer science research organization for decades. And you presume that he's not familiar with sum types, because if he was, he would have included it, and therefore he can't have been familiar with it, because he didn't include it? That's the most amazingly arrogant thing I've heard in a while. The fact is that Rob almost certainly knows more than you, rather than less. And he still made the choices he made. That should make you ask questions, not about Rob's knowledge, but about yours.
- crimsonalucard 7y ago
  He certainly does know more than me and is more successful than me and is smarter than me. But there are many areas of research in computer science. I'm saying Rob Pike is likely not to have been familiar with sum types and type theory in general (which is more Math then computer science). The design of his language looks that way. Someone knowing much more or having clearly a higher rank does not mean they know everything. And there are certainly things that you, I or Rob Pike doesn't know. Idolization of people and assumptions based off of reputation are highly biased and unrealistic. Counter my arguments with logic and evidence. Stuff like this person is "better than you" therefore you must be wrong is weak. Never have I ever directed a direct insulting statement AT someone on HN. You literally called me ARROGANT. Do not insult me. This is a place where we discuss things not a place where we insult people. I will have no further discussion with someone who directly and explicitly insults me. Don't bother responding, I will not discuss anything with someone who cannot be civil.
- thatswrong0 7y ago
  This feels like the opposite of an ad hominem fallacy
  - AnimalMuppet 7y ago
    Well... those Bell Labs types were polyglots. They tried a lot of things in a lot of languages. Does that mean that Rob Pike knew about sum types? Not necessarily, no. But it gives you two possibilities. 1. Rob Pike spent all that time at Bell Labs, with all these CS experts, read and wrote all those papers, and never heard about sum types. That's... possible. It's not the way I would bet, but it's possible. 2. Rob Pike knew perfectly well what sum types were, and left them out of Go, because he thought they didn't fit with what he was trying to do. To me, the second is both more charitable, and more in line with what I think Rob Pike's background and experience would have exposed him to. crimsonalucard obviously disagrees. He seems to think that sum types are so obviously the right thing that Pike could not have possibly not put them in Go had he known about them, and therefore he could not have known. And that is in fact possible. But it seems to me to better fit with Pike's background, as well as with the principle of charity, to assume that he knew. And still he chose to leave them out. Now, he could still be wrong. And we can discuss whether sum types are really a good fit for what Go is trying to do. But the assumption that he couldn't have known, or he would have done it the way someone else thinks he should have, is what grates on me. For what it's worth, the Go FAQ (at https://golang.org/doc/faq#variant_types https://golang.org/doc/faq#variant_types) says that they considered sum types, and didn't think they fit.
m0zg 7y ago
To me, Go is "masturbation prevention" language. Meaning that certain deliberate design choices were made to prevent precisely the types of endless unproductive masturbation you see in some other languages. I.e. type masturbation in Haskell or OOP/IoC masturbation in Java (particularly egregious, Java is not a bad language otherwise), or metaprogramming mastrurbation in C++. The omission of these features is not a bug. It's a feature in itself.
- crimsonalucard 7y ago
  Yeah, I get you. And I kinda agree. Still in my opinion, just the inclusion of parametric polymorphism and sum types won't make the language masturbatory. I feel what makes something like haskell "masturbatory" is really the monads, functors, operator overloading, function composition and a bunch of other advanced stuff. I'm not saying Go should have included those things... All I want are just parametric polymorphism and sum types.
- _ph_ 7y ago
  Indeed. More than once, I have seen program projects ruined by creating an overly elaborate class hierarchy, sometimes 10 layers deep. Just to express any theoretical aspect of the domain in the structure of the class hierarchy. Java programs often suffer from this. Which is especially sad, as Java has interfaces, which I think are the right way of representing abstract types for APIs for example. Interfaces don't force you to into a type inheritance just to fulfil a contract. But unfortunately, they are way to rarely used.
  - m0zg 7y ago
    If anything in Java they're overused. You often see only one class implementing an interface where the programmer can reasonably expect there will never be another implementation, and where it's not exposed outside the API boundary, so the interface is gratuitous.
- codygman 7y ago
  After a while typing `if err != nil` or reimplementing sorting for your custom data type pretty masturbatory in my experience. Is a language without generics plus "masturbation prevention" more economical than a language with generics where code review is used as "masturbation prevention"?

foldr 7y ago

Having the value returned together with the error is convenient for a couple of reasons. First, it's often possible for the function to return a meaningful value even in an error case (e.g., number of bytes read before the error occurred). Second, it's often possible to return a sensible 'null' value together with an error which can be handled correctly without checking the error value. (A map lookup is the obvious example of this.) This simplifies logic in some places. Using sum types for errors in Go wouldn't actually work very well unless you fundamentally changed other aspects of the language. You'd need pattern matching, a whole bunch of generic higher order functions for manipulating option/result types, etc. etc.

crimsonalucard 7y ago
>First, it's often possible for the function to return a meaningful value even in an error case Create a type that explicitly stores this information. The return type can hold the (error message and a value) OR (just a value). This type expression is a more accurate description of what's really going on. Whichever way you want to represent the product type it's not isomorphic to the actual intended result that the function should return. A sum type can represent the return value of the sentence below while GO cannot: "A function that returns (a value) OR an (error with a value)" This is the true intention of the function you described. >Second, it's often possible to return a sensible 'null' value together with an error which can be handled correctly without checking the error value. (A map lookup is the obvious example of this.) This simplifies logic in some places. But opens up the possibility of a runtime error if you fail to check for it. Historically there are tons of functions in C, C++ or javascript that use null to represent an error and it is self quoted to be the greatest mistake ever made by the creator of null. No language needs a null. >Using sum types for errors in Go wouldn't actually work very well unless you fundamentally changed other aspects of the language. You'd need pattern matching.... Using product types to represent errors has already changed the nature of GO in a very hacky way. Only Functions in GO can return tuples and the concept of the tuple can never be used anywhere else. You cannot save a variable as a tuple, you cannot pass a tuple as an argument. You can only return a tuple then instantly unroll it. It's an arbitrary hacky feature obviously made to support error values. It would be better to have an arbitrary pattern matching feature... this makes more sense then arbitrary tuples returned from functions. >a whole bunch of generic higher order functions for manipulating option/result types, etc. etc. Actually no you don't. The fact that go functions return tuples with errors, does this mean that higher order functions need to handle tuples? No! not at all. In fact go explicitly eliminates support for this... The tuples in GO need to be unrolled into their constituent types before they can be used in any other function. The same concept can be applied to Option types. You have to unroll the value and explicitly handle either individual type. You do not ever need a higher order function that accepts the Option type as a parameter. Like all languages that have the Option Type/Maybe Monad etc... Any function that returns this type represents a function that is impure that needs to be unrolled first before passing the value down to the functions that do closed and pure calculations. A function that takes an Option type as a parameter is a function that says "I am a function that can only take values from IO" It's very rare for functions to be implemented like this even in languages that have first class support for the sum type and Monads. In haskell I can't recall ever seeing a function that takes the IO monad as a parameter. In haskell and in Rust these values need to be unrolled into their constituent types before they can be used. Please note I am not advocating the inclusion of Monads into GO. Just talking about sum types.

AnimalMuppet 7y ago

He was at the premiere computer science research organization for decades. And you presume that he's not familiar with sum types, because if he was, he would have included it, and therefore he can't have been familiar with it, because he didn't include it? That's the most amazingly arrogant thing I've heard in a while. The fact is that Rob almost certainly knows more than you, rather than less. And he still made the choices he made. That should make you ask questions, not about Rob's knowledge, but about yours.

crimsonalucard 7y ago
He certainly does know more than me and is more successful than me and is smarter than me. But there are many areas of research in computer science. I'm saying Rob Pike is likely not to have been familiar with sum types and type theory in general (which is more Math then computer science). The design of his language looks that way. Someone knowing much more or having clearly a higher rank does not mean they know everything. And there are certainly things that you, I or Rob Pike doesn't know. Idolization of people and assumptions based off of reputation are highly biased and unrealistic. Counter my arguments with logic and evidence. Stuff like this person is "better than you" therefore you must be wrong is weak. Never have I ever directed a direct insulting statement AT someone on HN. You literally called me ARROGANT. Do not insult me. This is a place where we discuss things not a place where we insult people. I will have no further discussion with someone who directly and explicitly insults me. Don't bother responding, I will not discuss anything with someone who cannot be civil.
thatswrong0 7y ago
This feels like the opposite of an ad hominem fallacy
- AnimalMuppet 7y ago
  Well... those Bell Labs types were polyglots. They tried a lot of things in a lot of languages. Does that mean that Rob Pike knew about sum types? Not necessarily, no. But it gives you two possibilities. 1. Rob Pike spent all that time at Bell Labs, with all these CS experts, read and wrote all those papers, and never heard about sum types. That's... possible. It's not the way I would bet, but it's possible. 2. Rob Pike knew perfectly well what sum types were, and left them out of Go, because he thought they didn't fit with what he was trying to do. To me, the second is both more charitable, and more in line with what I think Rob Pike's background and experience would have exposed him to. crimsonalucard obviously disagrees. He seems to think that sum types are so obviously the right thing that Pike could not have possibly not put them in Go had he known about them, and therefore he could not have known. And that is in fact possible. But it seems to me to better fit with Pike's background, as well as with the principle of charity, to assume that he knew. And still he chose to leave them out. Now, he could still be wrong. And we can discuss whether sum types are really a good fit for what Go is trying to do. But the assumption that he couldn't have known, or he would have done it the way someone else thinks he should have, is what grates on me. For what it's worth, the Go FAQ (at https://golang.org/doc/faq#variant_types https://golang.org/doc/faq#variant_types) says that they considered sum types, and didn't think they fit.

m0zg 7y ago

To me, Go is "masturbation prevention" language. Meaning that certain deliberate design choices were made to prevent precisely the types of endless unproductive masturbation you see in some other languages. I.e. type masturbation in Haskell or OOP/IoC masturbation in Java (particularly egregious, Java is not a bad language otherwise), or metaprogramming mastrurbation in C++. The omission of these features is not a bug. It's a feature in itself.

crimsonalucard 7y ago
Yeah, I get you. And I kinda agree. Still in my opinion, just the inclusion of parametric polymorphism and sum types won't make the language masturbatory. I feel what makes something like haskell "masturbatory" is really the monads, functors, operator overloading, function composition and a bunch of other advanced stuff. I'm not saying Go should have included those things... All I want are just parametric polymorphism and sum types.
_ph_ 7y ago
Indeed. More than once, I have seen program projects ruined by creating an overly elaborate class hierarchy, sometimes 10 layers deep. Just to express any theoretical aspect of the domain in the structure of the class hierarchy. Java programs often suffer from this. Which is especially sad, as Java has interfaces, which I think are the right way of representing abstract types for APIs for example. Interfaces don't force you to into a type inheritance just to fulfil a contract. But unfortunately, they are way to rarely used.
- m0zg 7y ago
  If anything in Java they're overused. You often see only one class implementing an interface where the programmer can reasonably expect there will never be another implementation, and where it's not exposed outside the API boundary, so the interface is gratuitous.
codygman 7y ago
After a while typing `if err != nil` or reimplementing sorting for your custom data type pretty masturbatory in my experience. Is a language without generics plus "masturbation prevention" more economical than a language with generics where code review is used as "masturbation prevention"?