4 ms·

I just don't see, in properly designed code, that there would be that much use for sum types if you have generics. When are you creating functions take or retu

I just don't see, in properly designed code, that there would be that much use for sum types if you have generics. When are you creating functions take or return radically different types that need to be expressed this way? I dislike dynamic languages where parameters and variables can take on any type -- it's rarely the case that same variable/parameter would ever need to contain a string, a number, or a Widget in the same block of code. I find it much more freeing to have the compiler be in charge of exactness so I can make whatever changes I need knowing that entire classes of mistakes are now impossible.

deleted 6y ago
[deleted]
Ar-Curunir 6y ago
Rust has both generics and sun types, and benefits enormously from both. And sum types aren’t for “radically different types”. You can define an error type to be one of different options (I.e. a more principled error code), or to represent nullability in the type system, or to indicate fallibility without relying on exceptions, etc. Rust uses all of these to great effect, and does so because these sum types are generic.
GolDDranks 6y ago
Because even with generics, you are not able to express "or"; two different choices of types that have _different_ APIs. With generics, you can express n different choices of types that have all the _same_ API. It's a good software engineering principle to make control and data flow as streamlined as possible, for similar data. Minimize branches and special cases. Generics help with this, they hide the "irrelevant" differences, surfacing only the relevant. On the other hand, if there are _actually_ different cases, that need to be handled differently, you want to branch and you want to express that there are multiple choices. Sum types make this a compiler-checked type system feature.
- deleted 6y ago
  [deleted]
coolreader18 6y ago
Let's take Rust's hash map entry api[0], for example. How would you represent the return type of `.entry()` using only a class hierarchy? let v = match map.entry(key) { Entry::Occupied(o) => { o.get_mut() += 1; o.into_mut() } Entry::Vacant(v) => { update_vacant_count(v.key()); v.insert(0) } }; I view sum types as enabling the exact same exactness as you describe in your last line; especially since you can easily switch/match based on a specific subtype if you realize you need that, without adding another method to the base class and copying into the x subclasses that you have for implementing the different behavior. [0]: https://doc.rust-lang.org/std/collections/hash_map/enum.Entry.html https://doc.rust-lang.org/std/collections/hash_map/enum.Entr...
frenchy 6y ago
> When are you creating functions take or return radically different types that need to be expressed this way Let's say you're opening a file that you think is a CSV. There can be several outcomes: - the file doesn't exist - the file can't be read - the file can be read but isn't a valid CSV - the file can be read and is valid, and you get some data All of these are different types of results. You can get away with treating the first 3 as the same, but not the last. Without a tagged union, you'll probably resort to one of a few tricks: - You'll have some sort of type with an error code, and a nullable data field. In reality, this is a tagged union, it's just that your compiler doesn't know about it and can't catch your errors. - you'll return an error value and have some sort of "out" value with the data: this is basically the same as the previous example. - you'll throw exceptions, which usually ends up with people writing code that forgets about the exception because the compiler doesn't care about it, and the code works 99% of the time until it completely blows up.
- Mirioron 6y ago
  Honest question: do you think this kind of stuff is going to be adopted by the majority in the next decade or two? Because I'm looking at it and adding even more language features like that seems to make it even harder to read someone else's code.
  - wokwokwok 6y ago
    um... you realize the parent post is talking about having sum types in statically typed languages (eg. rust), when you already do this all the time in dynamic languages like javascript and python right? So, I mean, forget 'the next decade or two'; the majority of people are doing this right now; python and js are the probably the two most popular languages in use right now. Will it end up in all statically typed languages? Dunno; I guess probably not in java or C# any time soon, but swift and kotlin support them already). ...ie. if your excuse for not wanting to learn it is that it's probably an edge case that most people don't have to care about now, and probably never will, you're mistaken I'm afraid. It's a style of code that is very much currently in use.
    - 6y ago

deleted 6y ago

[deleted]

Ar-Curunir 6y ago

Rust has both generics and sun types, and benefits enormously from both. And sum types aren’t for “radically different types”. You can define an error type to be one of different options (I.e. a more principled error code), or to represent nullability in the type system, or to indicate fallibility without relying on exceptions, etc. Rust uses all of these to great effect, and does so because these sum types are generic.

GolDDranks 6y ago

Because even with generics, you are not able to express "or"; two different choices of types that have _different_ APIs. With generics, you can express n different choices of types that have all the _same_ API. It's a good software engineering principle to make control and data flow as streamlined as possible, for similar data. Minimize branches and special cases. Generics help with this, they hide the "irrelevant" differences, surfacing only the relevant. On the other hand, if there are _actually_ different cases, that need to be handled differently, you want to branch and you want to express that there are multiple choices. Sum types make this a compiler-checked type system feature.

deleted 6y ago
[deleted]

coolreader18 6y ago

Let's take Rust's hash map entry api[0], for example. How would you represent the return type of `.entry()` using only a class hierarchy? let v = match map.entry(key) { Entry::Occupied(o) => { o.get_mut() += 1; o.into_mut() } Entry::Vacant(v) => { update_vacant_count(v.key()); v.insert(0) } }; I view sum types as enabling the exact same exactness as you describe in your last line; especially since you can easily switch/match based on a specific subtype if you realize you need that, without adding another method to the base class and copying into the x subclasses that you have for implementing the different behavior. [0]: https://doc.rust-lang.org/std/collections/hash_map/enum.Entry.html https://doc.rust-lang.org/std/collections/hash_map/enum.Entr...

frenchy 6y ago

> When are you creating functions take or return radically different types that need to be expressed this way Let's say you're opening a file that you think is a CSV. There can be several outcomes: - the file doesn't exist - the file can't be read - the file can be read but isn't a valid CSV - the file can be read and is valid, and you get some data All of these are different types of results. You can get away with treating the first 3 as the same, but not the last. Without a tagged union, you'll probably resort to one of a few tricks: - You'll have some sort of type with an error code, and a nullable data field. In reality, this is a tagged union, it's just that your compiler doesn't know about it and can't catch your errors. - you'll return an error value and have some sort of "out" value with the data: this is basically the same as the previous example. - you'll throw exceptions, which usually ends up with people writing code that forgets about the exception because the compiler doesn't care about it, and the code works 99% of the time until it completely blows up.

Mirioron 6y ago
Honest question: do you think this kind of stuff is going to be adopted by the majority in the next decade or two? Because I'm looking at it and adding even more language features like that seems to make it even harder to read someone else's code.
- wokwokwok 6y ago
  um... you realize the parent post is talking about having sum types in statically typed languages (eg. rust), when you already do this all the time in dynamic languages like javascript and python right? So, I mean, forget 'the next decade or two'; the majority of people are doing this right now; python and js are the probably the two most popular languages in use right now. Will it end up in all statically typed languages? Dunno; I guess probably not in java or C# any time soon, but swift and kotlin support them already). ...ie. if your excuse for not wanting to learn it is that it's probably an edge case that most people don't have to care about now, and probably never will, you're mistaken I'm afraid. It's a style of code that is very much currently in use.
  - 6y ago