Hacker News Reader

Comment by crimsonalucard1 | Hacker News Reader

Don't forget about Go:

    func Open(name string) (file *File, err error)

Your basic Optional/Maybe monad would have worked better here.

There is a lot of evidence supporting the fact that Rob Pike and company when inventing Go were not aware of Sum types indicating that this special Tuple return type (that can never be reused anywhere and must be pattern matched immediately after it returns) was created because of lack of knowledge and not as a design choice.

See this thread as evidence: https://news.ycombinator.com/item?id=6821389

View on HN

Limbo, one of Pike's (et al) predecessor languages to Go, did have sum types, called there "pick adts".

Some people are ridiculously daring at dismissing others's reputations without the most basic of background checks.

Hold on. Instead of saying "some people" you should be more direct in what you mean. You should say, YOU and refer to me directly and have your words be inline with your intentions.

Now that being said. Go looks to me, to indeed be made by someone who doesn't know that a sum type exists. In my link Rob Pike himself admits that he didn't know about structural typing.

Additionally Rob seems to be in general not up to date on type theory. Please follow and read the link above to see what I'm talking about.

Now, that being said. Never EVER did I dismiss Rob Pikes background. He's done great things. Now I will say something exactly in line with my intentions: You have told an utter lie where you accused me of dismissing Rob Pikes reputation. I have done NO such thing.

Additionally one question. What site are you using to run a background check? doesPikeKnowWhatASumTypeIs.com? Sometimes people make mistakes. I admit the possibility that I'm wrong, but limbo is kind of an obscure programming language. It's not easy to given that they use the term discriminated union type rather then the "sum type."

I would argue that although this type is included in limbo, Rob likely didn't use it too much or know about its use case to bring errors into the type system as he could have easily used it in Go. I could be completely wrong here but one thing is not wrong:

>Some people are ridiculously daring at dismissing others's reputations without the most basic of background checks.

Accusatory language like this even disguised with "Some people" and that are additionally utter lies are not an acceptable way to start a discussion.

Where did you learn (or, more generally, where do people learn) about those Sum types?

The Wikipedia page for "Sum type" redirects to "Tagged union", implying those are synonyms; do you agree with that?

Sadly, that Wikipedia page only seems to refer to pages specific to some programming languages.

Could you maybe recommend an introductory book about type theory, preferably with an orientation to how it can be applied to language design? EDIT: or maybe a programming language theory book? To be honest, I am mainly interested in imperative languages, basically how could a better Go have been made.

Languages with Algebraic Data Types will help you get practical knowledge on how to use these types. Basically types share an isomorphism with algebra allowing certain types to share properties with algebra, hence the name sum types and product types.

Bool has a cardinality of two. True and False. A Product type (essentially a tuple) of two bools represents a bool and another bool and has a cardinality of 4. (True, True), (True, False), (False, False), (False, True). The cardinality of a product type is essentially the product 2 * 2 of the cardinality of both individual types. Product types represent the concept of AND: a bool AND another bool. The product type in itself is a type evaluated as the product of two (or more) types. In most languages this concept is represented as a struct or a tuple.

To remove confusion for sum types let us create a type with a cardinality of 4. FuzzyBool. It has 4 instances: VeryTrue, SortaTrue, SortaFalse, VeryFalse. A sum type represents the concept of OR. Let's see a sum type of a Bool OR a FuzzyBool (Bool + FuzzyBool). The new type can either be one of: (True | False | SortaTrue | SortaFalse | VeryTrue | VeryFalse). The cardinality is 4 + 2. Hence the term sum type.

Languages are typically asymmetric in types due to the lack of the explicitly offering the user the ability to combine types to form a sum type.

The Golang return value for functions is actually the opposite of a sum type. It is a product type. Rob Pike was likely unaware that you can create a type that is either (File* or Error) and instead utilized ((File* | null) && (Error | null)) to attempt to keep error handling within the type system. It results in IO functions having a return type with Cardinality of greater than 4: (File, nil), (File, err), (nil, nil), (nil, err) and they just expect you to ignore (File*, err) and (nil, nil) and assume it will never occur even though the type system does not restrict it from occurring.

If you want to learn this stuff imperatively I would recommend Rust, however you could miss the big picture with Rust due to the borrow checker and the option to do typical C-style programming that avoids utilizing the ADT's to the full extent of their power.

I would recommend diving into something like Haskell and getting to know algebraic data types and exhaustive pattern matching. You can avoid fully understanding Monads if all you want to understand is Sum types. Haskell will force you to utilize sum types very early on via exhaustive pattern matching.

Types and Programming Languages[0] by Benjamin C. Pierce is a good introduction to type theory and programming languages.

[0] https://www.cis.upenn.edu/~bcpierce/tapl/

Reply on news.ycombinator.com