4 ms·

I dunno if I'd consider having a dummy method on an interface as "elegant", but it does work. A trade-off of keeping the language very simple, for sure. What I

by jchw 3y ago

I dunno if I'd consider having a dummy method on an interface as "elegant", but it does work. A trade-off of keeping the language very simple, for sure. What I really wish Go had was sum types, Rust style. That'd cover enumerations and more.

jjice 3y ago
I go back and forth on this. On one hand, I _love_ Rust/ML style sum types. They're such a fantastic feature. On the other hand, I wonder how much use they'd get in a language like Go. If it's introduced, would it radically change the way some problems get solved? Is it that different than an traditional enum (which Go also skirts around)? Pattern matching and exhaustive checks are massive benefits of them though. I guess I'm just oddly conflicted here. I do think that long term, sum types are going to become more prevalent. I'm excited to see it, I'm just interested in how that adoption occurs in existing languages without them.
- jchw 3y ago
  If I had sum types in Go, I'd use them for state machines and enumerations mostly. I can't see a huge downside; I'm sure some software has little use for it, but it's useful enough for data modelling that protobuf has the sort-of similar oneof primitive. Hmm. On that note, maybe it would be better than nothing to do some kind of code generation here...
- jerf 3y ago
  I think the answer to your "back and forth" is probably laid out in: https://jerf.org/iri/post/2960/ https://jerf.org/iri/post/2960/ Sum types are useful, even very useful in the right place, but I do think there's a lot of people who use them a couple of times, probably in one of those "right places" and then mistakenly label them in their mind as "better". Just, universally, Platonically "better". They aren't in fact "better"; they're a tool. Sometimes they're the right tool for the job, but much, much more often, they're just a tool that works, and so do several other tools. People who get too excited about sum types need to be sure they square their understanding of how useful they are with the fact that the vast majority of programs are written without them.
  - jchw 3y ago
    This article seems almost entirely concerned with code organization, but in my case I basically never do functional programming and am only concerned about data modelling and data structures. In an adjacent, comment I do acknowledge one point (probably not all software really needs sum types) but I still feel as though languages without sum types are missing an important data and state modelling tool. Trying to take something like a state machine and jam it into interfaces or polymorphism kind of sucks; you lose exhaustiveness checking obviously, but also it enforces a lot of constraints about control flow and data. In Go parlance, if each of my states has a method with its receiver set to the state type, then I can only access that data, so for example I'd need to pass something in or out to handle state transitions. Not ideal IMO. I feel this pain basically any time I hand-write lexical scanners/parsers in Go or even C++.
    - masklinn 3y ago
      > I still feel as though languages without sum types are missing an important data and state modelling tool. That's because they are. jerf subtly shifts the point to one they can criticise, but it does not change the basic fact that sum types are a critical tool which is just... missing. There's probably no tool which can't be misused, even the humble boolean, that's not an issue with the tool, and pointing that out is at best irrelevant. It does not change the fact of the matter: you're missing a critical axis of composition. It's like saying screwdrivers are useful but you can misuse them to hammer nails as if that justified trying to screw with a hammer.
      - jerf 3y ago
        Where I'd disagree is that they are a tool, not a critical tool, and they aren't missing from Go, they are simply not the preferred choice. You can cover 75% of the use cases with this approach. It is not 100% of the use cases. But there isn't a language where you can cover 100% of the use cases with 100% effectiveness, which is why we don't have and never will have The One True Language. Moreover, Go seems to attract this sort of criticism as if Go is Uniquely Broken and it's nirvana in all the other languages... but I've used enough of them to know better. Sum types are great, until you hit the branch of the expression problem where you really need the other side, and if you're in a language that favors them, you're going to get the same 75% experience, just mirror imaged.
- Zach_the_Lizard 3y ago
  Sum types with pattern matching would likely take the place of (foo, error) in a lot of codebases. This is especially true in cases where a function returns a collection of results where each result is independent from other results and a result can succeed or fail. For instance, a batch report generator that is called every $INTERVAL might return a ([]Report metadata, error) today, but each report could have succeeded or failed without impacting the others. The output is emailed to $SOMEONE to let them know the reports ran and information about each. In today's world, the "error" could be a special error type that capture failures on a per report basis. The ReportMetadata type could also have an Error field, but one is not forced to check either. Sum types could force checking for error on a per report basis, increasing the odds something is done with the error.
jerf 3y ago
If you are satisfied with a dummy method on an interface, you can continue by adding more types to that interface. Color is not a great example, so: type Vehicle interface { isVehicle() } type Car struct {} func (c Car) isVehicle() {} type Van struct {} func (v Van) isVehicle() {} func VehicleType(vehicle Vehicle) { switch v := vehicle.(type) { case Car: fmt.Println("car") case Van: fmt.Println("van") default: fmt.Println("unknown vehicle") } This covers most, but not all, of the bases, in that you don't get exhaustiveness checking at compile time, unless you adjoin a linter to your compile process: https://github.com/BurntSushi/go-sumtype https://github.com/BurntSushi/go-sumtype
- jchw 3y ago
  Yeah, I've done that before. It's not really elegant in my opinion, but OTOH, it's basically the best you can do. Oh well.
fsdjkflsjfsoij 3y ago
I hope Go will eventually get sum types but I hope they're better than Rust's where each variant is its own type.
- LatticeAnimal 3y ago
  How is this mess better than Rust's enums? A Rust enum + match statement results in really easy to read and clean code.
  - fsdjkflsjfsoij 3y ago
    For a trivial example, let's say I have some message type that has multiple variants with differing fields: enum Message { Action1(String, Option<Mode>), Action2(String), } Action1 and Action2 are variants not types and I cannot make functions that take an Action1 or an Action2 as a parameter. To get around this people will often make each enum variant just a container for some struct with the same name but that's more verbose and matching becomes slightly uglier. Code like this is fairly common: struct Action1(String, Option<Mode>); struct Action2(String); enum Message { Action1(Action1), Action2(Action2), } Ideally I'd like to be able to succinctly say something like: type A = B | C and have A be dependent on B and C but have both B and C be completely independent types.
    - LatticeAnimal 3y ago
      That is a pretty compelling point... I ran into this less than an hour ago and was slightly frustrated. Though, I still like the flexibility of adding additional fields to `Action1`. In golang I end up with fields that are conditionally populated based on the state of an Enum which is less than ideal and leads to lots of error checking (though this is relatively rare). It doesn't have to be one or the other though. A bit more polishing on the Rust-style enums (perhaps in a different language) could lead to pretty ergonomic code.
- sapiogram 3y ago
  > Rust's where each variant is its own type. Is this... right? You can't use enum variants as types in function signatures, variable declarations, etc.

by jchw 3y ago

jjice 3y ago

I go back and forth on this. On one hand, I _love_ Rust/ML style sum types. They're such a fantastic feature. On the other hand, I wonder how much use they'd get in a language like Go. If it's introduced, would it radically change the way some problems get solved? Is it that different than an traditional enum (which Go also skirts around)? Pattern matching and exhaustive checks are massive benefits of them though. I guess I'm just oddly conflicted here. I do think that long term, sum types are going to become more prevalent. I'm excited to see it, I'm just interested in how that adoption occurs in existing languages without them.

jchw 3y ago
If I had sum types in Go, I'd use them for state machines and enumerations mostly. I can't see a huge downside; I'm sure some software has little use for it, but it's useful enough for data modelling that protobuf has the sort-of similar oneof primitive. Hmm. On that note, maybe it would be better than nothing to do some kind of code generation here...
jerf 3y ago
I think the answer to your "back and forth" is probably laid out in: https://jerf.org/iri/post/2960/ https://jerf.org/iri/post/2960/ Sum types are useful, even very useful in the right place, but I do think there's a lot of people who use them a couple of times, probably in one of those "right places" and then mistakenly label them in their mind as "better". Just, universally, Platonically "better". They aren't in fact "better"; they're a tool. Sometimes they're the right tool for the job, but much, much more often, they're just a tool that works, and so do several other tools. People who get too excited about sum types need to be sure they square their understanding of how useful they are with the fact that the vast majority of programs are written without them.
- jchw 3y ago
  This article seems almost entirely concerned with code organization, but in my case I basically never do functional programming and am only concerned about data modelling and data structures. In an adjacent, comment I do acknowledge one point (probably not all software really needs sum types) but I still feel as though languages without sum types are missing an important data and state modelling tool. Trying to take something like a state machine and jam it into interfaces or polymorphism kind of sucks; you lose exhaustiveness checking obviously, but also it enforces a lot of constraints about control flow and data. In Go parlance, if each of my states has a method with its receiver set to the state type, then I can only access that data, so for example I'd need to pass something in or out to handle state transitions. Not ideal IMO. I feel this pain basically any time I hand-write lexical scanners/parsers in Go or even C++.
  - masklinn 3y ago
    > I still feel as though languages without sum types are missing an important data and state modelling tool. That's because they are. jerf subtly shifts the point to one they can criticise, but it does not change the basic fact that sum types are a critical tool which is just... missing. There's probably no tool which can't be misused, even the humble boolean, that's not an issue with the tool, and pointing that out is at best irrelevant. It does not change the fact of the matter: you're missing a critical axis of composition. It's like saying screwdrivers are useful but you can misuse them to hammer nails as if that justified trying to screw with a hammer.
    - jerf 3y ago
      Where I'd disagree is that they are a tool, not a critical tool, and they aren't missing from Go, they are simply not the preferred choice. You can cover 75% of the use cases with this approach. It is not 100% of the use cases. But there isn't a language where you can cover 100% of the use cases with 100% effectiveness, which is why we don't have and never will have The One True Language. Moreover, Go seems to attract this sort of criticism as if Go is Uniquely Broken and it's nirvana in all the other languages... but I've used enough of them to know better. Sum types are great, until you hit the branch of the expression problem where you really need the other side, and if you're in a language that favors them, you're going to get the same 75% experience, just mirror imaged.
Zach_the_Lizard 3y ago
Sum types with pattern matching would likely take the place of (foo, error) in a lot of codebases. This is especially true in cases where a function returns a collection of results where each result is independent from other results and a result can succeed or fail. For instance, a batch report generator that is called every $INTERVAL might return a ([]Report metadata, error) today, but each report could have succeeded or failed without impacting the others. The output is emailed to $SOMEONE to let them know the reports ran and information about each. In today's world, the "error" could be a special error type that capture failures on a per report basis. The ReportMetadata type could also have an Error field, but one is not forced to check either. Sum types could force checking for error on a per report basis, increasing the odds something is done with the error.

jerf 3y ago

If you are satisfied with a dummy method on an interface, you can continue by adding more types to that interface. Color is not a great example, so: type Vehicle interface { isVehicle() } type Car struct {} func (c Car) isVehicle() {} type Van struct {} func (v Van) isVehicle() {} func VehicleType(vehicle Vehicle) { switch v := vehicle.(type) { case Car: fmt.Println("car") case Van: fmt.Println("van") default: fmt.Println("unknown vehicle") } This covers most, but not all, of the bases, in that you don't get exhaustiveness checking at compile time, unless you adjoin a linter to your compile process: https://github.com/BurntSushi/go-sumtype https://github.com/BurntSushi/go-sumtype

jchw 3y ago
Yeah, I've done that before. It's not really elegant in my opinion, but OTOH, it's basically the best you can do. Oh well.

fsdjkflsjfsoij 3y ago

I hope Go will eventually get sum types but I hope they're better than Rust's where each variant is its own type.

LatticeAnimal 3y ago
How is this mess better than Rust's enums? A Rust enum + match statement results in really easy to read and clean code.
- fsdjkflsjfsoij 3y ago
  For a trivial example, let's say I have some message type that has multiple variants with differing fields: enum Message { Action1(String, Option<Mode>), Action2(String), } Action1 and Action2 are variants not types and I cannot make functions that take an Action1 or an Action2 as a parameter. To get around this people will often make each enum variant just a container for some struct with the same name but that's more verbose and matching becomes slightly uglier. Code like this is fairly common: struct Action1(String, Option<Mode>); struct Action2(String); enum Message { Action1(Action1), Action2(Action2), } Ideally I'd like to be able to succinctly say something like: type A = B | C and have A be dependent on B and C but have both B and C be completely independent types.
  - LatticeAnimal 3y ago
    That is a pretty compelling point... I ran into this less than an hour ago and was slightly frustrated. Though, I still like the flexibility of adding additional fields to `Action1`. In golang I end up with fields that are conditionally populated based on the state of an Enum which is less than ideal and leads to lots of error checking (though this is relatively rare). It doesn't have to be one or the other though. A bit more polishing on the Rust-style enums (perhaps in a different language) could lead to pretty ergonomic code.
sapiogram 3y ago
> Rust's where each variant is its own type. Is this... right? You can't use enum variants as types in function signatures, variable declarations, etc.