Hacker News Reader

Comment by aazaa | Hacker News Reader

> Arguably the most-asked-about missing feature coming from object-oriented languages is inheritance. Why wouldn’t Rust let a struct inherit from another?

This concern faded away as I used Rust a lot. It turns out that inheritance of implementation isn't nearly as useful as it's cracked up to be. And it carries a lot of baggage.

The example hints at this, but unfortunately without driving the point home.

Rust's enums (used to illustrate static dispatch) are amazing, and one of the best (of many) language features. Enums can contain data of their own (as enum structs or enum tuples), opening up many more possibilities than the example might imply.

On two large projects, I've had no need for inherit-the-implementation style OO. And it's just fine.

View on HN

> Rust's enums (used to illustrate static dispatch) are amazing, and one of the best (of many) language features. Enums can contain data of their own (as enum structs or enum tuples), opening up many more possibilities than the example might imply.

Algebraic data types are table stakes for any programming language in my book. I don't know why it's taken OOP programmers so long to come around to them (and most still haven't). It bothers me that Rust calls them "enums", even though "enum" already means something different to most programmers and we already have several terms that describe the feature that Rust has (coproducts, variants, sum types, discriminated unions, tagged unions, and, more generally, algebraic data types). This makes talking about programming languages more difficult than it needs to be, since when someone says "enums" I now have to ask what programming language they are referring to, since "enum" now means different things in different languages.

I think because if you're building with a language that's extremely interface oriented you probably don't want to think "if it's this type, do x, if it's that type do y" manually. Instead that would be another job for another interface. But I think that's more a symptom of having a powerful hammer than actually designing well, and sum types solve a different problem than interfaces.

I always thought of Rust's enums as simply a generalization of other languages' enum concepts, not a completely different thing.

Yes, that is what they are, but a generalization of a thing is not the same as the specific thing, and in this case the generalization already had other names (since it has been around for many decades in many other languages). It would have been preferable to use one of the existing names instead of adding a new one and thereby complicating the story.

Swift also has sum types called "enums". I thought it was overly cute, the same way it has errors (not exceptions) but uses the C++ exception syntax for them. Seems to work though.

The naming of enums was a bit of a stumbling block for me in my learning Rust journey, but once I got past that, I'm doing fine. I'm finding the language wonderfully expressive and while I still find myself changing fn foo(bar: Baz) to fn foo(&bar: Baz) a lot (and related issues) as I write, the compiler does a good job of explaining what I'm doing wrong. I have never encountered any compiler (or other application) with as good of error messages as Rust provides.

Agreed, I think calling them enums is an example of trying a little too hard to make the language seem comforting and familiar to c/c++ programmers at the expense of clarity.

Reply on news.ycombinator.com