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

> Rust's enums and exhaustive match statement are just amazing

ADTs + pattern matching are the killer feature set that makes the more popular functional languages so damn pleasant to use, and they're starting to spread to more and more languages. I suspect that, 50 years from now, we'll look back and see them as the key paradigm shift of this era.



This. I have no idea why people underestimate the conceptual power of ADTs. Every time I try to explain this concept they just disregard it as just a convenient wrapper over union...and union isn't THAT common right..?

Turns out that having a much better tagged union opens up so many possibilities. Software deals with states and what's better to represent states than an ADT? Last time I was fixing an issue where a mouse position is initialized to (0.0f,0.0f) and causes it to trigger a mouse event on startup. The fix was to simply turn it into an Option<(f64,f64)> which is so much better than initializing them as (-1.0f,-1.0f) because it forces you to check all the places where you do arithmetic operations on them.


> This. I have no idea why people underestimate the conceptual power of ADTs.

Blub. It's one of those conceptual steps which seems to have no benefit until it actually clicks and you realise how much it opens or does. Being a tremendously good educator is necessary to make people take that step without experience.


I'll bite - I just googled this, and am having a struggle understanding.

Is an Algebraic Data Type (ADT) in rust an enum or tuple? I make heavy use of enums (along with structs) as my program foundations. Am I using ADTs?

The third type the query shows are unions, which I'm not familiar with.


> Is an Algebraic Data Type (ADT) in rust an enum or tuple?

It's the combination of both.

Tuples are Product Types. If you treat types as sets of values, then the type (A,B) is the cartesian product of types A and B. For all practical purposes, structs are just syntactic sugar for tuples. Enums are Sum Types. The values of Result<T, E> are fundamentally just all the values of T plus the values of E (with a tag to tell them apart). Put the two things together, and enum Coordinates{TwoD(f32, f32), ThreeD(f32, f32, f32)} is a set of values with cardinality #f32^2 + #f32^3. You can build types corresponding to arbitrary polynomials, hence the name.

"Union type" usually just means the same as "sum type", though it can also be used to mean C-style unions specifically.

(There's also functions as exponential types, with A -> B having cardinality #B^#A, but you're neck deep in type wankery when you start talking about those :o)

Almost every language supports product types in some way, either implicitly or explicitly, and nobody really bothers talking about those in isolation. It's when you add sum types to the mix that people start talking about ADTs, and it's when you add pattern matching that the whole thing comes into its own and you can just express functions as "things with this shape become things with that shape".


Union types and sum types are different things. Given a type 𝐴:

𝐴 + 𝐴 ≠ 𝐴

𝐴 ∪ 𝐴 = 𝐴


That's an outstanding explanation!


Enums are Sum Types, which are a type of ADT[1]. Tuples are a Product Types, which are another type of ADT[2]; Sum Types are so called because when you add one to that, you add just one more possibility (It could be A,B now it can be A,B,C). Product Types, on the other hand, give out possibilities based on their Product, so if you add a new property, you multiply it (A,B can both be two things, so you have 4 possibilities, if you add C that can also be two things, then you now have 8 possibilities).

This is a good explanation: https://jrsinclair.com/articles/2019/algebraic-data-types-wh...

[1]https://en.wikipedia.org/wiki/Tagged_union

[2]https://en.wikipedia.org/wiki/Product_type


I found https://guide.elm-lang.org/appendix/types_as_sets.html is friendly describing the what and why.


You are. But benefit depends how your language is utilizing it. Do your function type check your struct input at compile time? Do your condition statement compiled error when you miss addressing a complete set of enum?


They’re enums that can hold additional data types.

But they’re additionally great because the compiler does exhaustive pattern matching.


ADTs is last missing piece that would make me fully content with Go :)


I agree, I love that Go is simple but it is simply too...simple. It makes it hard to represent a much harder state transformations.


aren't interfaces technically an abstract data type?

EDIT: ah, it's algebraic data types, my bad, apologies.


Interfaces are not closed, which is considered a big advantage of sum types (though it can also be a disadvantage).


> we'll look back and see them as the key paradigm shift of this era.

You mean the key paradigm shift of the 1970s when they were invented. Only took 50 years for it to go semi-mainstream.


Going mainstream is the paradigm shift.

OOP was invented in the 60s/70s, but the paradigm shift came in the 80s/90s.


Yeah, it's interesting to see them become a part of Java with records, sealed types, and pattern matching. However, I haven't seen much uptake yet.


Most Java libraries want to keep compatibility with Java 8, or at most Java 11; there will be more uptake of these kinds of features once the baseline becomes Java 17, which will probably still take a long time.


As a Scala dev I agree.


True. But there are more features out there (such as typeclasses) which are also extremely important and need to become mainstream. We are really not quite there yet.


What makes functional languages so damn pleasant to use is the fact that closures are cleaned up automatically by the runtime system once you're done with them.


Could you give some detail? Is it true for functional language that has mutable data structure and reference as well? How does it clean up, are you talking about "closure conversion"?


Pity that it took people 50 years to discover them.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: