7 ms·

Probably quotes like: "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural lang

Probably quotes like: "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical." And not including sum types despite having a sum-type-shaped hole in the language (`if err != nil`). And some of the discussion about "why no generics" seemed kind of divorced from existing PL knowledge on the topic.

tensor 3y ago
These were all intentional tradeoffs though, not any ignorance of theory. Also, it's pretty rich for someone to be complaining about Go while referencing Javascript of all languages. Javascript's design flaws are legendary. And I mean no disrespect to the creators of Javascript, they had to deal with some crazy last minute change requests to the language.
- kaba0 3y ago
  With all the crazy warts that JS has, it is at least a lisp-like very dynamic language if you squint (a lot) at it. Its greatest fault is probably leaving out integers (I can’t even fathom why they decided on that, floats can’t represent properly ints). Go is just simply badly designed, relying on hard-coded functionality a lot.
  - Cthulhu_ 3y ago
    Which is better, hard-coded functionality or magic? I don't believe it's badly designed, since every design decision is deliberate; bad design would be accidental.
    - za3faran 3y ago
      This is a false dichotomy. golang is weak that things that should have been in the standard library end up being hardcoded (like maps).
- TwentyPosts 3y ago
  Ehhh, I see absolutely no evidence that the Go developers were particularly aware of theory. It really feels more like they just were used to thinking in terms of C, and built a language which is kind of like C. Go also has some really weird stuff in it, such as named return values. Frankly, the lack of sum types hurts the most. The language would just be a lot better with a unifying Result type in the library. And don't give me any of that "oh, they tried to keep the language simple!" stuff. Intuitively, sum types are laughably simple. Everyone understands "It's one of these possible values, so you need to check which one it is and then handle that situation." They are more simple than enums on a conceptual level! Sum types are just not how C-programmers think about the world.
  - ianlancetaylor 3y ago
    As it happens, we considered sum types quite seriously in the early days. In the end we decided that they were too similar to interface types, and that it would not help the language to have two concepts that were very similar but not quite the same. https://groups.google.com/g/golang-nuts/c/-94Fmnz9L6k/m/4BUxp-JqZFUJ https://groups.google.com/g/golang-nuts/c/-94Fmnz9L6k/m/4BUx... There is a lot of discussion of sum types in Go at https://go.dev/issue/19412 https://go.dev/issue/19412.
    - TwentyPosts 3y ago
      When I did research on this topic ages ago I read both of these links, and I'm very familiar with the arguments. I also vehemently disagree with them, and I think that the way code is factually written in practice is on my side: People who propose sum types commonly refer to the Option<T> or Result<S,E> types in Rust. These are types which are almost exclusively used as return types. Interface types are the opposite. They're used as input types, and almost never to distinguish between a concrete, finite list of alternatives. They are used to describe a contract, to ensure that an input type fulfills a minimal set of requirements, while keeping the API open enough that other people can define their own instances. The fact that Go in fact does not use interface types for its error handling is a pretty good argument in favor of that, I'd say. The thing is, at this point it doesn't matter, sadly. Adding sum-types to the language now would be unsatisfying. You would really need proper integration as the primary tool for error handling in the standard library (and the ecosystem), and that's unlikely to happen, even less likely than a Go 2.0. EDIT: Just to make it clear, I think not wanting to add sum types to the language is understandable at this point. The real shame is that they were not in the language from the beginning.

tensor 3y ago

These were all intentional tradeoffs though, not any ignorance of theory. Also, it's pretty rich for someone to be complaining about Go while referencing Javascript of all languages. Javascript's design flaws are legendary. And I mean no disrespect to the creators of Javascript, they had to deal with some crazy last minute change requests to the language.

kaba0 3y ago
With all the crazy warts that JS has, it is at least a lisp-like very dynamic language if you squint (a lot) at it. Its greatest fault is probably leaving out integers (I can’t even fathom why they decided on that, floats can’t represent properly ints). Go is just simply badly designed, relying on hard-coded functionality a lot.
- Cthulhu_ 3y ago
  Which is better, hard-coded functionality or magic? I don't believe it's badly designed, since every design decision is deliberate; bad design would be accidental.
  - za3faran 3y ago
    This is a false dichotomy. golang is weak that things that should have been in the standard library end up being hardcoded (like maps).
TwentyPosts 3y ago
Ehhh, I see absolutely no evidence that the Go developers were particularly aware of theory. It really feels more like they just were used to thinking in terms of C, and built a language which is kind of like C. Go also has some really weird stuff in it, such as named return values. Frankly, the lack of sum types hurts the most. The language would just be a lot better with a unifying Result type in the library. And don't give me any of that "oh, they tried to keep the language simple!" stuff. Intuitively, sum types are laughably simple. Everyone understands "It's one of these possible values, so you need to check which one it is and then handle that situation." They are more simple than enums on a conceptual level! Sum types are just not how C-programmers think about the world.
- ianlancetaylor 3y ago
  As it happens, we considered sum types quite seriously in the early days. In the end we decided that they were too similar to interface types, and that it would not help the language to have two concepts that were very similar but not quite the same. https://groups.google.com/g/golang-nuts/c/-94Fmnz9L6k/m/4BUxp-JqZFUJ https://groups.google.com/g/golang-nuts/c/-94Fmnz9L6k/m/4BUx... There is a lot of discussion of sum types in Go at https://go.dev/issue/19412 https://go.dev/issue/19412.
  - TwentyPosts 3y ago
    When I did research on this topic ages ago I read both of these links, and I'm very familiar with the arguments. I also vehemently disagree with them, and I think that the way code is factually written in practice is on my side: People who propose sum types commonly refer to the Option<T> or Result<S,E> types in Rust. These are types which are almost exclusively used as return types. Interface types are the opposite. They're used as input types, and almost never to distinguish between a concrete, finite list of alternatives. They are used to describe a contract, to ensure that an input type fulfills a minimal set of requirements, while keeping the API open enough that other people can define their own instances. The fact that Go in fact does not use interface types for its error handling is a pretty good argument in favor of that, I'd say. The thing is, at this point it doesn't matter, sadly. Adding sum-types to the language now would be unsatisfying. You would really need proper integration as the primary tool for error handling in the standard library (and the ecosystem), and that's unlikely to happen, even less likely than a Go 2.0. EDIT: Just to make it clear, I think not wanting to add sum types to the language is understandable at this point. The real shame is that they were not in the language from the beginning.