Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sum types are finally coming to C#. That’ll make it the first “Mainstream” language to adopt them. Will it be as solid and simple as Haskell’s implementation? Of course not. Will having a backing ecosystem make up for that deficiency? Yes.


What counts as mainstream for you?

Java has recently added sealed classes/interfaces which offer the same features as sum types, and I would argue that Java is definitely mainstream.

Kotlin has a similar feature. It might be used less than Java, but it's the default language for Android.

Swift has `enum` for sum types and is the default language for iOS and MacOS.

Likewise for Rust, which is gaining traction recently.

Typescript also has union/sum types and is gaining lot of traction.


For that matter, PASCAL has had variant records (i.e. sum types) since the 1970s.


Did it have an ergonomic way to exhaustively match on all the variants? Since the 70s?

How does the ABI work? If a library adds a new constructor, but I am still linking against the old version, I imagine that it could be reading the wrong fields, since the constructor it's reading is now at a different index?


Sealed classes still won't let you have e.g. String|Integer, though I'll grant you that java is certainly mainstream.


You don't really need `String|Integer`, for most usecases an isomorphic type that you can exhaustively pattern match on is more than enough, and sealed classes (along with the support in `switch` expressions) does exactly that.


Scala 3 has had union types for 4 years now. Scala can be used to do Haskell style pure FP, but with much better tooling. And it has the power of the JVM, you can fall back to Java libraries if you want.


Rust is mainstream, just not use in enterprise applications


AWS uses Rust extensively


Not really, other mainstream languages got there first.


Python has sum types

optional_int: int | None = None


This is semantically not the same as a sum type (as understood in the sense of Rust, which is afaik the academically accepted way)!

Python's `A | B` is a union operation, but in Rust a sum type is always a disjoint union. In Python, if `A = B = None`, then `A | B` has one possible instance.

In Rust, this sum type has two possible instances. This might not sound like a big deal, but the semantics are quite different.


Sorry, I could not grok the difference, even after reading a few Rust examples.

def foo(int | None = None) ...

... just means the variable's default value is None in a function definition. But it could be either in an actual function call.


There's no difference there because the types are already disjoint.

Say you wanted to define some function taking `YYMMDD | MMDDYY`. If both YYMMDD and MMDDYY are just aliases to `str`, then you gain no information, you cannot discriminate on which one it is, since the union `str | str` just reduces to `str`.

Sum types are disjointed unions, you can't just say `str | str`, the terms are wrapped in unique nominal data constructors, like:

enum Date { MMDDYY(String), YYMMDD(String) }

Then when accepting a `Date` you can discriminate which format it's in. You could do the same in Python by defining two unique types and using `MMDDYY | YYMMDD`.


Every dynamically typed language effectively has one big Sum type that holds all of the other types. IMO this is one reason why dynamic languages have been so popular (because Sum types are incredibly useful, and mainstream statically typed languages have historically had very poor support for them).


I like this observation! It explains a lot.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: