3 ms·

I went years without using a language with sum types and was fine. As soon as I was exposed to them, I was hooked. They just make so much sense in so many place

by jjice 3y ago

I went years without using a language with sum types and was fine. As soon as I was exposed to them, I was hooked. They just make so much sense in so many places, especially in trees. It seems that over the past five or so years, they've been adopted more as pattern matching has. If they're not an explicitly feature of the language, then they can be replicated (like with Java sealed classes). I'm not sure if Go would ever implement them, or add something that we can more easily replicate sum types with, but god damn are they my favorite language feature that so few languages properly support. I wouldn't have expected Go to implement them, but after generics and range over functions, I feel like anything could be game.

rightbyte 3y ago
A nullable pointer is a sum type and Go has them.
pjmlp 3y ago
Go doesn't need to go full speed on sum types, plain basic Pascal enumerations from 1970 instead of that hacky iota/const dance, would be a huge improvement already.
- randomdata 3y ago
  There is no practical difference between enums in Pascal and Go. What is different is that Pascal added an additional layer over enumerations – what is basically a poor man's sum types – to hide that there are enums under the hood. In fact, one has to perform an explicit conversion if they want to access the enum. Sum types predate enums, and no doubt they were trying to stay close to sum type semantics without the overhead. Something later languages, like C and Go, chose to forego in favour of exposing the enums naturally. But if you're going to go to all the trouble of implementing a poor man's sum types, why not just do it properly? It's not 1970 anymore. We've solved the overhead problems. Sum types are perfectly viable these days.
  - pjmlp 3y ago
    Of course not, first Go would need to actually have support for proper enumerations. Go neither has the 1970 Pascal enumerations, nor the 1976 ML sum types. Both approaches too advanced to implement on 2009, apparently. We don't want the poor minds Go is targeted at, as per Rob Pike's words, to have imposter syndrome learning the language. As it is, is a non starter to even bother.
    - randomdata 3y ago
      It is Pascal that does not truly support enums, if such a thing can be said. It has them, technically, but the language is not designed to meaningfully make use of them. The poor man's sum types abstraction works to hide their existence. While sum types first appeared in Algol 68, there were some unsolved issues at the time. So Pascal came along with its half-assed 'sum types' as a tradeoff between the benefits of true sum types and what was tenable given the constraints of the time. But there is no reason for any language created in the last 50 years to follow in that path. We've long solved the problems they had. Go benefits from enums because it has a very basic type system. Trying to improve on enums by extending the type system, along the lines of what Pascal did or otherwise, is hilariously nonsensical. If you are going to build a better type system, just get rid of enums completely. You don't need them. Sure, it was a reasonable compromise in 1970, but it is not 1970 anymore.
      - pjmlp 3y ago
        Go still hasn't catched up with either 1970 nor 1976, no matter how many words you happen to write. An idiotic hack, remains an idiotic hack.
        randomdata 3y ago
        Are you expecting this straw man that you keep wanting to talk with to come to life and follow you down a yellow brick road, or what? Yes, enums are a hack, forever and always. Nobody disputes this.
    - 3y ago

by jjice 3y ago

rightbyte 3y ago

A nullable pointer is a sum type and Go has them.

pjmlp 3y ago

Go doesn't need to go full speed on sum types, plain basic Pascal enumerations from 1970 instead of that hacky iota/const dance, would be a huge improvement already.

randomdata 3y ago
There is no practical difference between enums in Pascal and Go. What is different is that Pascal added an additional layer over enumerations – what is basically a poor man's sum types – to hide that there are enums under the hood. In fact, one has to perform an explicit conversion if they want to access the enum. Sum types predate enums, and no doubt they were trying to stay close to sum type semantics without the overhead. Something later languages, like C and Go, chose to forego in favour of exposing the enums naturally. But if you're going to go to all the trouble of implementing a poor man's sum types, why not just do it properly? It's not 1970 anymore. We've solved the overhead problems. Sum types are perfectly viable these days.
- pjmlp 3y ago
  Of course not, first Go would need to actually have support for proper enumerations. Go neither has the 1970 Pascal enumerations, nor the 1976 ML sum types. Both approaches too advanced to implement on 2009, apparently. We don't want the poor minds Go is targeted at, as per Rob Pike's words, to have imposter syndrome learning the language. As it is, is a non starter to even bother.
  - randomdata 3y ago
    It is Pascal that does not truly support enums, if such a thing can be said. It has them, technically, but the language is not designed to meaningfully make use of them. The poor man's sum types abstraction works to hide their existence. While sum types first appeared in Algol 68, there were some unsolved issues at the time. So Pascal came along with its half-assed 'sum types' as a tradeoff between the benefits of true sum types and what was tenable given the constraints of the time. But there is no reason for any language created in the last 50 years to follow in that path. We've long solved the problems they had. Go benefits from enums because it has a very basic type system. Trying to improve on enums by extending the type system, along the lines of what Pascal did or otherwise, is hilariously nonsensical. If you are going to build a better type system, just get rid of enums completely. You don't need them. Sure, it was a reasonable compromise in 1970, but it is not 1970 anymore.
    - pjmlp 3y ago
      Go still hasn't catched up with either 1970 nor 1976, no matter how many words you happen to write. An idiotic hack, remains an idiotic hack.
      - randomdata 3y ago
        Are you expecting this straw man that you keep wanting to talk with to come to life and follow you down a yellow brick road, or what? Yes, enums are a hack, forever and always. Nobody disputes this.
  - 3y ago