My favorite Rust design pattern
ฝัง
- เผยแพร่เมื่อ 9 ก.ค. 2024
- Today we are discussing one of my favorite Rust design patterns... extension traits! Along the way, we will learn about Rust's unusual orphan rule and a best practice Rust library authors should follow!
Free Rust cheat sheet: letsgetrusty.com/cheatsheet - วิทยาศาสตร์และเทคโนโลยี
Get your *FREE Rust cheat sheet* :
letsgetrusty.com/cheatsheet
chrono not chorno
chrono not chorno
No arch users were hurt during the making of this video
i'm offended. Ubuntu and Manjaro are the 2 distros i absolutely refuse to have on my device. the closest distro to Ubuntu that is actually great is Mint.
@@bocchitherock-ob2bl why
@@kchaitanya39 Ubuntu: 1st reason is Unity, 2nd is sudo apt install firefox. Manjaro: the devs don't know what they are doing, they recommend not using the aur on manjaro (which is my main reason for using arch) but still made pamac and ddos'ed the aur servers 2 times.
Btw, i use arch
@@bocchitherock-ob2bl I used Ubuntu exclusively for 13 years and then switch to the next meme distro Manjaro. I had enough after 1.5 years.
C# extension method has been one of my favorite features, and I am really happy to see it being loved in other mainstream languages. (I do love Rust and Kotlin)
I said in a work meeting that I like using "chorno", now I'm having a sit-down with HR 🤷
I wasn't redirected. I guess my fingerprint is too hardened.
I actually find it quite funny 😅
as an arch user I can tell: my user agent does not contain Arch.
as an arch user, they do not need a user agent to identify us
@@motozirillo true
First time I've heard an explanation of the orphan rule that made sense. Thank you, haha.
I got you!
Nice! Rust enables extending the standard types without the global "prototype pollution" style problems of JS.
There's a typo at the end, you wrote chorno instead of chrono
It's not a typo. It's the Ukrainian equivalent of the n-word.
its not delivery, its dechorno
Or was it...
Thank you for talking about this! I think this trips up allot of people and you explained it nicely.
I had to think about it just recently because someone asked me how you could implement Copy for Rc, exactly this problem.
Yes, an extension trait is a very powerful. I wildly used it in Swift and now in Rust;
Very clear demonstrations of some very cool features of Rust.
As an Arch user I would appreciate a bigger challenge 😂
Wow, this is really powerful to extend functionality of crates we use and need to customize for our needs. Thanks for sharing!
Thanks for watching Luis! :)
damn, i really love the "chorno" crate, wow, the "chorno" crate is truly the best!
I am the great chornolio! I need TZ for my crate hole! Heh! Heh! Mmm.
@@steamer2k319 haha, a classic!
Thank you Bogdan! great leason.
Дякую, Богдане!
4:20 cheeky
4:24 you graciously flashbanged the shit out of me lmao
Well done --- one of your best!
Could you remove the need for Clone by storing only the hashes rather than the Items?
I now did try to use the extension trait design pattern to to "override" / enhance the .into() method of the Error type to allow for an &String.
I did not succeed. Is this possible ?
Does it work with decorators like wasm_bindgen ? thanks
Oh! Why the rule exists is so logical I'm shocked I never put two and two together.
Started my pc, went to the website, but nothing. No redirect. Sad :((
Nice video. One funny thing though. You spelled Chrono wrong in the end of the video...
chorno is my favorite Rust design pattern.
The main aspect of the orphan rule not mentioned, is the part that gives it it's name: that you can't have the trait implementation orphaned from the trait or struct it's working with. So you don't have third party crates implementing traits on structs and fucking everything up
How would you even bring that into scope?!?! Nobody knows.
what if two extension traits from different crates have the same name?
You can only use functionality from the extension trait if you import it. And rust won't let you import two traits with the same name. But you can import those traits using different names, which will cause ambiguity. Then you'll need to specify, function from which trait to use
I understand the possibility for conflicting implementations exist, but if that's truly the reason, why not simply check for those conflicts at compile time and allow them if no conflicts exist? It seems like it would be perfectly fine to implement a foreign trait on a foreign struct, it seems hardly necessary, but why prohibit it? It doesn't seem like a bad idea to me, and your external User example is a use case I come accross all too frequently, particularly with the Debug trait which I use extremely often (probably like most people)
Imagine if there was a trait A and type TA in crate ca, crates cb and cc both have different implementations of A for TA. And if this issue only pops up when all 3 crates are used together, it will be a pain
@@InfiniteCoder01 Ohhhh, I see, I was only thinking from a final user's prespective (i.e. someone making an app, not someone making a crate). Thanks!
And if you want to skip the boiler plate, just use the extend crate.
While I need to do my own example for the extension trait I'd like to comment on deriving external structs (which I did e.g. for Error) : struct MyError (Error).
This allows for implementing external traits on that type. (I did this e.g. with From )
Unfortunately now I need to access the original features of Error by "my_error.0".
IMHO it would be beneficial in this (and other) situation, if the compiler could infer the ".0" automatically, if only a single element is defined in a tuple struct and the item is found there.
What do you think ?
But don't you think doing it for tuple is bit explicit, and not that necessary, as it's providing those features in other forms?
@@adityanithariya first I did a simple function that created a new error with the text in the argument. I found that not very "iconic" but wanted to use "into()" or "from()". That was possible by doing the derived struct (and using same all over the place instead of "Error"). But doing an extension trait and staying with the "Error" type would be even more "iconic", if that is possible,
@@michaelschnell5633 Yeah, that would be modular and more friendly!
@@adityanithariya an even more obvious example:
I can do:
let i:i32 = 1;
let f: f64 = x.into();
I even can do
fn ff(f: F) -> f64{
f.into()
}
let i:i32 = 1;
let f = ff(i);
and have the compiler infer the appropriate "From" when calling the function with whatever type !!!!.
but I can't do
let i:i64 = 1;
let f: f64 = x.into();
-> the trait `From` is not implemented for `f64`, which is required by `i64: Into`
this is obviously OK, as it would loose accuracy.
But what if I in my project know that the all i64 will be small enough, I don't care about loosing accuracy or want a panic if the u64 is too big ?
How could I implement a custom From for f64 ?
I am not allowed to do
impl From for f64{};
even though the lack of same exactly is the error message above :( (hence no ambiguity)
@@adityanithariya A way to implement a default filed for structs (the fields and methods of which would be usable as fields and methods of the main struct) could be to define same by an appropriate #[.... attribute to such field, By that there would be no danger to break any existing code.
I think, the orphan rule has some interesting "political" implications.
Because of the orphan rule, people are more likely to contribute to a library they are using instead of implementing something themself.
And it's more likely that communities form around some specific crate.
For example basically every crate uses serde.
If I write my own serialization library, it's very difficult to use it with popular crates.
So if I want some custom serialization, I either have to write my own library or have to cretae some wrapper library or something like that.
It's pretty annoying and something like this might lead to a split in the ecosystem, where some libraries use the one crate and others use the other crate.
as someone who uses ubuntu and who used to have arch on a previous machine; ubuntu is really annoying. Its not a rolling release and in order to get Sid installed you have to jump through a bunch of silly hoops to get it. Arch is actually up to date (if a *little* unstable.. but so is sid..) and doesn't require a special terminal ceremony to upgrade.
Emotional damage for Arch users
Babe wake up new LGR just dropped.
4:25 send NixOS users to an arch linux installation tutorial
5:17 rename UniqueIterator to Unique to comply with the stdlib naming conventions
What are stdlib naming conventions?
@@adityanithariya At least for Iterators, it is just the name of the iterator like: Map, Slice or Filter (check it out)
Y'all, any good mobile frameworks in Rust yet? Every time I need to write Dart for Flutter I want to throw myself off a bridge. Can't figure out a simple ffi that'd work for me to have Rust as backend to Flutter, so I want to change completely.
Why is the orphan rule even a thing? wouldn't the compiler be able to detect that you are implemetning a trait that results in a conflict and just abort the compilation and in all other cases let you define the trait?
How about the case where you use 2 libraries, each of them has an implementation of trait A for type B?
@@ToanNguyen-ue8rw well then you can't use both of those at the same time ¯\_(ツ)_/¯ . This as a feature would still be useful in binary (just non-lib) crates
i think one of the reasons it exists is to make sure that if a library author in a next version implemented some trait for library's internal type then it would not be a breaking change, all the code that used that lib can just update its version.
about toan's case, i think i heard about this reason a lot, it must be the main one, but i feel like that problem could be solved with introduction of some more explicit kind of fully-qualified method call syntax that would allow specifing from which crate to take trait's implementation. i guess there must be another considerations which led to existence of orphan rule in it's current form though.
@@anamoyeee A well structured binary project usually has one or more libs and a main where most functionalities are provided in the libs, the main acts as user interface. This design allows you to export your functionalities just in case for others to use. So, if we only allow it in non-lib case, you have to modify your libs in case you want to make a library out of your project.
It's really annoying to sometimes write the newtypes, but it's a necessary evil to prevent malicious libraries from sneakily doing some nefarious things, like, rewriting + operator of the u32 to also dump the Firefox/chrome passwords, cookies, and maybe set up a SSH server with a reverse shell as a backdoor for the lib creator. Or maybe just full-on destroying the root. If you think it can't happen - it can, due to some internal conflicts one dev could easily push a new version as a patch, and, if the lib was popular, it would take no time until some users will get caught in this crossfire. (Normally, patch suffixes are omitted in the cargo.toml and therefore will seem as if it's the same version, allowing users who see it, use the malicious newest one)
I wasn't redirected :(, I use arch BTW
I tried to change my user agent to "Arch Linux" too and it didn't work, which makes sense, but I was lowkey hoping he'd be that cheeky
1:00 this isn't what the orphan rule is about. This wouldn't work even without the orphan rule.
The orphan rule is about preventing you from adding unexpected behavior to a foreign type that is defined in a foreign trait.
For example there is the copy trait of the rust std library. You could implement it for any type changing the behavior for the type could result in the type not working like it was designed to.
Or an serializable trait in a serialization crate and a struct with Passwords in another crate that should not be serializable.
The orphan rule prevents a 3rd actor to break the contract or purposely lack of between a trait and a type.
The best extension method pattern in rust is obviously reverse refcast deref.
4:11 joke's on you: My user agent only says Linux and I use Arch btw x)
4:20 Ultrakill
arch btw. did not get redirected to Ubuntu install page and am extremely disappointed
4:28 💀
Wouldn't it be reasonable to ensure the proper working order of devices prior to requiring functionality of bother the phone and its user. I'n doing so you could avoid cases such as whats happening currently, which no script can remedy. Thar way I can leverage my ittorator more bettered. Because now ì behind schedule and in a worse mood that previously thought I could be in.
nyaa
I'm installing Ubuntu
Arch users are too busy to cancel you on the social network.
chorno lol 😂
make a wrapper then derive(Deref)
yes that's anti pattern no I don't care
first-ish! :)