I don't know if there's a meaningful difference between sum types and union types as both end up allowing a variable to be of one of a set of types. Ceylon:

I don't know if there's a meaningful difference between sum types and union types as both end up allowing a variable to be of one of a set of types. Ceylon: alias StringOrInt = String | Integer; StringOrInt myValue = "foo"; StringOrInt otherValue = 10; Rust: enum StringOrInt { Str(String), Int(usize), } let my_value: StringOrInt = StringOrInt::Str("foo"); let other_value: StringOrInt = StringOrInt::Int(10); In Ceylon, you're right you don't need to name a "union", which IMO makes it much nicer, as I was able to use adhoc unions everywhere, e.g. inside streaming operations: [ for x in foos if (x.something()) "foo" else 10 ] The above "automatically" has type `[String | Integer]`. In Rust (and Kotlin) I would need to name a type just for this. Another disadvantage of Rust's approach is that the type variants are not types themselves. That's really annoying sometimes, e.g. you want to have a method that only handles one of the variants, but you can't (you need to pass the values the variant wraps separately, but that may be undesirable semantically as that would allow something that has no instance of the enum to also use the function).