7 ms·
Rust Any part 3: we have upcasts
- jtrueb 2y agoGetting closer and closer to OOP
- diggan 2y agoAt least they're not expanding the standard library for reading emails, yet...
- the_mitsuhiko 2y agoI'm a bit confused by both this comment and the previous one. Fundamentally nothing new is unlocked by this, that wasn't already possible for many years. It's just the ergonomics that got much better through this change.
- BerislavLopac 2y agoThe second comment refers to Zawinski's Law [0]. [0] https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski's_Law https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski's_Law
- tialaramex 2y agoI can't speak for your parent but I'm aware of Zawinski's Law and I could see that's what the comment was about, but like your parent it's not at all clear to me why, it's a non-sequitur - this is giving Rust a convenient safe way to up cast, that's not anywhere in the ballpark of the sort of "expand to do everything" that Jamie was describing as inevitable. If you say "Ooh, the new kitten is learning how the cat flap works" and I respond "Those who cannot remember the past are condemned to repeat it" and then you respond with confusion that's because my quoting of Santayana is a non-sequitur. I might even agree with his sentiment about the importance of history, but the kitten learning how to use a cat flap isn't anywhere close to what Santayana was talking about so...
- diggan 2y agoMy jest wasn't meant to say that Rust is expanding to do everything, but rather the opposite. The comment I replied to somehow seems to believe Rust is becoming more "OOP", so I took it a step further and also referenced a fairly known pitfall for platforms (so doesn't even apply to programming languages, in my mind). In the end, it's a joke with no even a pinch of truth, which seems to have landed flat, that's on me I suppose.
- capitol_ 2y agoSince rust is popular it naturally attracts a counter movement, so some people will grasp at straws in order to say something negative.
- GolDDranks 2y agoJust having features associated with OOP isn't a bad thing. Object upcasting has its uses. It's some of the other stuff that gets OOP its bad rap. Garbage collection, common in many OOP languages, enables having arbitrary object graphs. The programmer doesn't need to think hard about who has a reference to who, and how long these references live. This leads to performance-defeating pointer chasing, and fuzzy, not-well-thought-of object lifetimes, which in turn lead to accidental memory leaks. Additionally, references in major languages are unconditionally mutable. Having long-lived mutable references from arbitrary places makes it hard to track object states. It makes easier to end up in unexpected states, and accidentally violate invariants from subroutine code, which means bugs. Also, class-like functionality conflates data-layout, privacy/encapsulation, API, namespacing and method dispatch into a single thing. Untangling that knot and having control over these features separately might make a better design.
- jtrueb 2y agoI agree this is useful. I also think it isn’t the end of the world to support some semblance of OOP in Rust. If it helps you ship the business logic, sometimes it’s okay to concede some performance or other cost.
- BrainInAJar 2y ago"sometimes" is doing a lot of work there. Sometimes it is, but also sometimes it isn't, and Rust at least gives you a choice (you can use Arc all over the place, or if performance is critical you can be more careful about specifying lifetimes)
- jtrueb 2y agoArc doesn’t give you the choice until this upcasting feature lands in stable.
- mightyham 2y agoYou make some really good criticisms of OOP language design. I take issue with the part about garbage collecting, as I don't think your points apply well to tracing garbage collectors. In practice, the only way to have "memory leaks" is to keep strong references to objects that aren't being used, which is a form of logic bug that can happen in just about any language. Also good API design can largely alleviate handling of external resources with clear lifetimes (files, db connections, etc), and almost any decent OOP languages will have a concept of finalizers to ensure that the resources aren't leaked.
- __s 2y agoDo you consider Go OOP?
- dullcrisp 2y agoI love how OOP is considered a slur on here. It’s no wonder Alan Kay doesn’t come back.
- Rexxar 2y agoWhy do you interpret this comment as anti-OOP ? I see it has criticising rust choice to not do OOP at the beginning to finally do it piece by price and that it would have probably be better for the language to embrace it from start.
- dullcrisp 2y agoI don’t know how to interpret the comment, but that seems to be how the other responses interpret it.
- bfrog 2y agoInherit is the first step to tell.
- dullcrisp 2y agoI don’t disagree about inheritance.
- Xeoncross 2y agoAre we talking about functional OOP or class-less OOP or JavaScript's prototypal version of inheritance in OOP or Javas functions-are-evil OOP or some other version of OOP? Object-Oriented Programming is a spectrum with varying degrees of abuse.
- bigstrat2003 2y agoOOP is a good thing, not a bad thing. It enables you to use objects to represent relationships easily in a way that other paradigms don't. I agree that the trendiness of OOP was stupid (it isn't the right approach to every situation and it was never going to solve all our problems), but the way it's trendy to hate on OOP now is equally stupid. It's a good tool that sometimes makes sense and sometimes doesn't, not a savior or a devil.
- vlovich123 2y ago“Inheritance” of interfaces good *. Inheritance of stateful objects bad - composition is much better. The OOP model that Rust supports only supports the good kind of OOP and doesn’t support the bad kind. * technically rust doesn’t have interface inheritance but you can treat it that way and it’ll mostly look like that in an abstract sense.
- jandrewrogers 2y agoI agree that composition is much better than inheritance for most typical code cases. However, there are cases where inheritance is absolutely the correct model and not having inheritance makes for worse code. I may not use inheritance very often (it rarely makes sense in a systems context) but it is nice to have it when it is unambiguously the right tool for the job. Most code paradigms exist because there is some code context where they are nearly ideal. Someone invented them to handle that case efficiently and elegantly. If you write diverse software long enough you will come across all of those contexts in real code. I’m the opposite of a model purist. I have a strong preference for a languages that let you efficiently switch models on a very granular basis as may be useful in the moment.
- zozbot234 2y ago> The OOP model that Rust supports only supports the good kind of OOP and doesn’t support the bad kind. Well, almost. You can actually express "the bad kind of OOP" (i.e. implementation inheritance) in Rust quite elegantly via the generic typestate pattern! But that's still good, because it reveals the inherent complexity of your 'inheritance hierarchy' very clearly by modeling every part of it as a separate, possibly generic type. Hence why it's very rarely used in Rust, with interface inheritance being preferred instead. It mostly gets used in cases where the improved static checking made possible by the "typestate" pattern can be helpful, which has little to do with "OOP" design as generally understood.
- echelon 2y agoRust has had significant OOP features since the beginning. Trait methods, dynamic dispatch, inheritance, bounds, etc.
- quotemstr 2y agoThere's this dynamic in the industry in which a brash young project comes out swinging against some established technique and commits early to its opposite. Then, as the project matures, its authors begin to understand why the old ways were the way they were and slowly walk back their early stridency --- usually without admitting they're doing it. Consider Linux. Time was, metaprogramming was BAD, C was all you needed, we didn't need dynamic CPU schedulers, we didn't need multiple LSMs, and we sure as hell didn't need ABI stability. Now we have forms of all of these things (for the last, see CO-RE), because as it turns out, they're actually good. In Python, well, turns out multiprocessing isn't all you need, and a free-threaded Python has transitioned from impossible and unwanted to exciting and imminent. In transfer encodings, "front end" people thought that JSON was all you needed. Schemas? Binary encodings? Versioning? References? All for those loser XML weenies. Well, who's the weenie now? And in Rust? Well, let's see. Turns out monomorphization isn't all you need. Turns out that it is, in fact, occasionally useful to unify an object and its behavior in a runtime-polymorphic way. I expect yeet_expr to go through eventually too. Others are trying to stabilize (i.e. ossify) the notionally unstable ABI, just like they did to poor C++, which is now stuck with runtime pessimization because somebody is too lazy to recompile a binary from 2010. As surely as water will wet and fire will burn, the gods of Java with stupidity and complexity return.
- Rusky 2y ago> And in Rust? Well, let's see. Turns out monomorphization isn't all you need. Turns out that it is, in fact, occasionally useful to unify an object and its behavior in a runtime-polymorphic way. I expect yeet_expr to go through eventually too. Others are trying to stabilize (i.e. ossify) the notionally unstable ABI, just like they did to poor C++, which is now stuck with runtime pessimization because somebody is too lazy to recompile a binary from 2010. Not to make an argument either way on your general point, but these are really bad examples for Rust if you look at the specifics: Monomorphization was never the only option. Trait objects and vtables predate the RFC process itself. Early Rust wanted more dynamic dispatch than it eventually wound up with. The idea of a "throw"-like operator was introduced at the same time as the `?` operator and `try` blocks: https://rust-lang.github.io/rfcs/0243-trait-based-exception-handling.html https://rust-lang.github.io/rfcs/0243-trait-based-exception-... (Okay, technically `?` was proposed one month previously.) All the various initiatives related to stable ABI are focused on opt-in mechanisms that work like `#[repr(C)]` and `extern "C"`. The only way to interpret these as examples of "brash young project walks back its early stridency as it ages" is if you ignore the project's actual reasoning and design choices in favor of the popular lowest-common-denominator Reddit-comment-level understanding of those choices.
- mmastrac 2y agoThe important change here appears to be that the internal representation of a vtable is now guaranteed to have its supertraits laid out in some predictable prefix form to its own methods. EDIT: or if this is not possible, a pointer to the appropriate vtable is included. I assume this must be for diamond trait inheritance.
- kibwen 2y ago> the internal representation of a vtable is now guaranteed to have its supertraits laid out in some predictable prefix form to its own methods. Importantly, note that the specifics of the vtable layout are not guaranteed, only the general property that the layout must be amenable to supporting this.
- the_mitsuhiko 2y agoAnd for extra context the RFC lays out the current design and future options: https://github.com/rust-lang/rfcs/blob/master/text/3324-dyn-upcasting.md https://github.com/rust-lang/rfcs/blob/master/text/3324-dyn-...
- nialv7 2y agoIIRC vtable happens to already be laid out the required way (barring some corner cases maybe, correct me if I am wrong), this RFC just made that official. And for diamond patterns vtable entries are duplicated.
- fcantournet 2y agoAny are you Debug ? Are you DebugAny ?
- aerzen 2y agoI like rust because Any is inconvenient. It pushes you to implement things with static typing.
- striking 2y agoYou may want to review the article linked from within the story. The original motivation here is not just to defeat the typechecker. It begins: > Let's say you want to have a wrapper around a boxed any that you can debug.
- trashface 2y agoThis example shows how it works for one trait, Debug, but what if you have a type that (might) implement multiple traits A, B, and/or C? It isn't clear to me if that is possible, unless the type implements all of those traits. What I'd like to do is have some base trait object and query it to see if it supports other interfaces, but also not have to have stub "I don't actually implement this" trait impls for the unsupported ones. A bit like how I might use dynamic_cast in c++. (I believe I understand that in rust this has not historically been possible because rust doesn't have inheritance, so, there can be only one vtable for a type, rather than an chain like you might have in c++.)
- vlovich123 2y agoI think you’ve just confused how traits are used. They’re more like Java interfaces and there’s no inheritance - if you have trait A: B it means whatever type implements a also separately and explicitly has to implement B. Multiple traits would work similarly - either the downcast would work if the type implements a trait or you’d get back a None when you try to downcast.
- mmastrac 2y agoYou can do something akin to QueryInterface from COM, though it's a bit verbose. https://play.rust-lang.org/?version=beta&mode=debug&edition=2024&gist=fd28aa228a2ca6e2ce8a9d30aef5b032 https://play.rust-lang.org/?version=beta&mode=debug&edition=... (ninja edited a few times with some improvements) With a bit of API massaging, this could be improved quite a bit in terms of ergonomics. The challenge is that traits often require concrete structs if you want them to participate in dynamic typing. Basically you can now make something like `Arc<dyn QueryInterface>` work, where multiple traits are available through a `query_interface`: fn main() { let x = Arc::new(X); let y = Arc::new(Y); let any = [x as Arc<dyn QueryInterface>, y as _]; for any in any { if let Some(a) = any.query_interface::<dyn A>() { a.a(); } if let Some(b) = any.query_interface::<dyn B>() { b.b(); } } }
- dathinab 2y agothe article isn't very good for anyone not already familiar with the problem > What I'd like to do is have some base trait object and query it to see if it supports other interfaces > rust doesn't have inheritance rust traits and lifetimes have inheritance, kinda, (through rust types do not) E.g. `trait A: Debug + Any` means anything implementing A also implements Debug and Any. This is a form of interference, but different to C++ inheritance. This is why we speaking about upcasts when casting `&dyn A as &dyn Debug` and downcast when trying to turn a `&dyn A` into a specific type. But because this inheritance only is about traits and the only runtime type identifying information rust has is the `Any::type_id()` the only dynamic cast related querying you can do is downcasting. (Upcasting is static and possible due to changes to the vtable which allow you to turn a `&dyn A` vtable into a `dyn Any`/`dyn Debug` vtable (in the example below). The part of bout downcast form the article you can ignore, it's some nice convenient thing implicitly enabled by the upcasting feature due to how `downcast_ref` works. This https://play.rust-lang.org/?version=beta&mode=debug&edition=2024&gist=9e502c213de951102a50c0f22a69c41b https://play.rust-lang.org/?version=beta&mode=debug&edition=... might help. So I think what you want might not be supported. It also is very hard to make it work in rust as you would conceptually need a metadata table for each type with pointer to a `dyn` vtable for each object safe trait the type implements and then link it in every vtable. The issue is concrete rust traits can be unbound e.g. a type `C` might implement `T<bool>` and `T<T<bool>>` and `T<T<T<bool>>>` up to infinity :=) So as long as you don't have very clever pruning optimizations that isn't very practical and in general adds a hidden runtime cost in ways rust doesn't like. Like e.g. if we look at `dyn T` it e.g. also only contains runtime type information for up casting if `T: SomeTrait` and downcasting if `T: Any` and the reason up casting took like 5+ years is because there are many subtle overhead trait offs between various vtable representations for `C: A+B` which might also affect future features etc.
- kibwen 2y ago> Even though DebugAny inherits from Any I'm going to push back against this terminology for the sake of people who don't know Rust and are coming from traditional OO languages. Rust traits don't "inherit" from other traits, they "require" other traits. So if I have two traits, where one requires the other: trait Foo {} trait Bar: Foo {} That doesn't add Foo's methods to Bar's list of methods, like you might expect from the term "inheritance". Instead, it just means that it's not possible to implement Bar for a type unless Foo is also separately implemented for that type. Despite this it's still accurate to say that this enables a supertype/subtype relationship in certain contexts, but be careful because Rust isn't a traditionally OO language, so that may not always be the most useful framing.
- d4mi3n 2y agoWhat's the practical distinction here? I agree with you that rust isn't OOP, but for the sake of communication and understanding--what's the practical difference between requiring a trait and inheriting from it?
- Rusky 2y agoIt means you can't just write `impl Bar for MyType` and get Foo pulled in automatically. You have to write both `impl`s yourself. The inheritance-like syntax is shorthand for `trait Bar where Self: Foo`, and bounds like this can show up in lots of other places, where they follow the same rules: `MyType` has to impl all of them, and the traits and bounds can have fairly arbitrary (or at least un-tree-like) relationships. The upcasting thing is a rare exception to the idea that this `Self: Foo` bound is just like any other bound.
- PeterWhittaker 2y agoIf Bar inherited from Foo, Bar would have Foo's methods. So if you implemented Bar for Gum, Gum would get Bar and Foo. But Bar requiring Foo means that if you want to use Gum in a place that expects Bar, Gum must have both Bar's methods and Foo's methods. In some cases, you might be able to derive some of those.
- pwdisswordfishz 2y ago
- the__alchemist 2y agoRust continues to blow my mind. It's been my most-used language for ~5 years, and I have no idea what this article is describing!