There is no real reason to have basic enums if you have ADTs , since those can easily provide everything a plain enum gives you.

I guess the name was just a historical artifact.

I agree (that’s what I meant under the more expressive part), though it is a bit more complex with identity in the way. Java’s enums are also the singleton pattern.

Java recently got ADTs as well in the form of sealed classes and records, here an enum would look like this:

  sealed interface Color permits Red, Blue, Green {

}

  record Red() {}
  record Blue() {}
  record Green() {}

You can now create as many Red instance as you want, they will be “equals” only under equals(), not under ==, while the latter is also true for the enum case.

The interface implementation types may include enums, though not sure that would help much in your example.

That's completely orthogonal to ADT vs enum.

Enums enable two things: check current type from union of types and exhaustivity check in switch

The former is solved by reflection, the latter by sealed classes.

I disagree. "Sum" and "product" types are really really unclear names that only make sense if you've studied some advanced CS and even then they're bad names - not descriptive at all.

Enum is much better - you just enumerate all the values the type can be (plus optional associated data).

Perhaps, though given that it is already used slightly differently in a very well-known language can also cause hiccups.

For the record, algebraic data types get there names from the fact that the “number” of instances that are under a given type gets added or multiplied together. Let’s say we have a ColorChannel “enum” of R, G, B. That is there are 3 instances ever under this ColorChannel type. Let’s create (with some syntactic sugar) an 8bit unsigned int which has exactly 256 possible instances.

Now create a Pair (ColorChannel, u8) type. This will be a product type, since the number of possible constituents is 3x256.

Let’s look at the often used Option type, which wraps another type. This looks something like enum Option<T> { Some(T), None }

We have two possible types here, but one can contain T possible types. So Some(T) is basically a product type of 1 other type, resulting in it holding that type’s cardinality, while None has a single instance — the Optional sum type thus has card(T)+1 possible instances.

Rust isn't alone though - Swift's `enum`s are essentially the same as Rust's enums.