Hacker News new | past | comments | ask | show | jobs | submit login

Problems that Rust can't now address are listed in that RFC. Such as sharing of fields between definitions for instance. Traits don't address that.

See also these posts:

* http://smallcultfollowing.com/babysteps/blog/2015/05/05/wher...

* http://smallcultfollowing.com/babysteps/blog/2015/05/29/clas...

* http://smallcultfollowing.com/babysteps/blog/2015/08/20/virt...

* http://smallcultfollowing.com/babysteps/blog/2015/10/08/virt...




Note that while many OOP patterns are hard to express in Rust, there are equivalent patterns that handle the use cases.

To give some context on those blog posts; they exist to figure out how to add single inheritance to Rust. One of the strongest arguments for single inheritance in Rust is "Servo and similar things need it to model the DOM". I.e; the strongest argument out there is that modelling cross-language things with languages that _do_ have single inheritance is hard.

That's not a very strong argument. That's a pretty niche use case (which Servo itself has moved past; we have a setup emulating inheritance that works pretty ok now).

So while I do agree that Rust can't model these patterns easily; I'm skeptical that that can be an issue for the large majority of Rust users.


> while many OOP patterns are hard to express in Rust, there are equivalent patterns that handle the use cases.

May be there are, but they far from trivial, and with the current level of documentation they are in the realm of some obscure hacks rather than straightforward part of the language. Which is a disadvantage. May be when The Book will cover OOP topics in depth and explain such patterns, or there will be some other dedicated documentation on this topic, things could become more clear.


> current level of documentation they are in the realm of some obscure hacks

I don't think so. Rust encourages a certain style of designing code, using enums and traits. Almost all the time this suffices.

My comment was at the macro level; I'm not saying that an OOP pattern will have an equivalent in Rust, I'm saying that if you look at the larger use case you can design your code in idiomatic Rust to avoid it.


> I'm saying that if you look at the larger use case you can design your code in idiomatic Rust to avoid it.

As I said, may be you can, but it's far from trivial and unless you know how to do it already, coming up with such approaches isn't something that one who just learns the language would be focusing on. You yourself said above, that it's hard. And unlike languages like C++ where OOP approaches are very well documented, Rust documentation lacks such kind of information at present.


> You yourself said above, that it's hard.

I said modeling single inheritance is hard. That's a very niche use case; basically only crops up when writing an interpreter for a language with single inheritance (and in cases like Servo's DOM)

> unless you know how to do it already, coming up with such approaches isn't something that one who just learns the language would be focusing on

Again, it's not a thing that you do as a drop-in for inheritance. I'm saying that the regular approach (i.e. using traits and enums idiomatically) to designing your application in Rust will cover the use cases for inheritance, differently.

Basically, don't try to write Rust code as if it's C++ or Java and stuff should work out.


I don't mean one has to copy ideas from C++ or Java to Rust verbatim, but having some explanation on how to use Rust OOP abstractions for solving common programming problems would be useful. I don't think current Rust documentation covers that well.


Ah, fair.


The book will never cover OOP directly, or at least, the book will always attempt to show Rust as Rust itself, not as in comparison to other languages. "OOP Patterns in Rust" is a very different book.

That said, the second draft of the book is placing a lot more emphasis on understanding how to write Rustic abstractions.


> "OOP Patterns in Rust" is a very different book.

Then may be there should be one like that :) May be it's just my personal impression, but I feel that such kind of documentation now is lacking.

OOP in Rust shouldn't necessarily focus on comparison with other languages (though explaining key differences would be very helpful). But it at least should explain common use cases that OOP expects the language to cover and approaches that Rust proposes for them.

Something like this would very useful in The Book (or some other book): https://lwn.net/Articles/548560/


Yeah, I think it would be a good book to have. It's just not one that I'm going to write. Hopefully someone else does!




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

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

Search: