Great point, I probably should have covered this as well - it would make things much more concise if you have lots of amphibious vehicles

@@mathijsfrank9268 I think you may be reading it the wrong way around. The example does not mean that being Amphibious implies being LandCapable. It means that, if you are LandCapable (regardless of whether you customize drive) and you are WaterCapable, that implies that you are Amphibious. So you still only have one implementation of drive, i.e. the one you go with when you implement LandCapable.

oh man, every day, after 5 years, I still learn something new about Rust.

gone*

You can also make T ?Size so it works on trait objects too. impl C for T {}

very true, good point! ditching inheritance makes code infinitely more readable imo...

That's a common misunderstanding of OO techniques. Composition and inheritances are two different patterns for two different needs (search for "has-a" and "is-a"), one doesn't simply replace the latter with the former. Rust just lacks inheritance at the moment, which leads to a class of issues for specific problems to solve, unfortunately. It's possible to work around but it requires to duplicate the code, which makes it hard to maintain. Or by using macros, which makes reading the code much more difficult.

Yes. Mostly. For game engine frameworks for instance you will need to store all data in one place like a vec for centralized storage so that you can do multi threading. That requires down casting which again requires up casting to Any first when you need access to data. For now up casting is an unstable feature. But it seems to work so far. The problem is that if you did cast to Any via your own functions inside a custom trait that is not Any. That you have to do that for any game node all over again because you can not make a default trait because of life time issues and seized issues. Horrible pain in the neck. But up casting is being stabilized so it is coming to stable Rust in the future.

@@phenanrithe Can you give examples? It would help

Is Rust even an object-oriented language?

Pretty sure the implications is that being "LandCapable" will do much more than just provide a single drive method. And on a small tangent. If your trait IS just what function. What's really the benefit os using a trait over just writing a generic drive function that you call as: drive(suv)? (Genuine question. Since I would be surprised if rust made some nice optimization in one case vs the other)

@@sebastiangudino9377 I think you are mixing things together. LandCapable is not a type, its a trait, so you can't pass it as a generic parameter. The correct call would be drive::(suv), but then think about what drive does: it has to work for all types that implement LandCapable, which means that you can only use functions from the LandCapable trait. But we have just decided to move the only function out of LandCapable, so drive can't really do anything meaningful now. Now let's look at why having a single function in a trait is a good thing. Suppose LandCapable has another method, I will call it fuel(). Now look at road_trip(): it only cares that its argument implements drive() and does not really care about fuel, so fuel() is redundant here, now imagine we have a bike that can't really be fueled. A better more flexible approach would be to have two traits: Drive and Fuel. Then functions that care only about drive will use just the first trait and some other functions will require both traits to be implemented - your code is more flexible! TLDR: think of traits not as objects but properties of objects, which work better when they are granular. Hopefully I made my point clear

@@BulbaWarrior Ups yeah, i mixed the Syntax up quite a lot. But you thankfully understood what I meant! And yeah, I guess you are right. Rust is deeply related to composition. Weird at first. But seems like a really nice abstraction as things scale up

WOW thank you so much Mark!! I really appreciate your support and your kind words. Thanks again for watching!

I like it as well!

What advantage do you mean?

It might be safer but it is not superior compared to traditional OOP languages because you need to write much more code

@@Tienisto Compared to Java or C++?

wow thank you so much for your support and kind words! more to come!

Nice, really happy it helped!

I think it's because most people didn't learn these concepts of composition as beginners to programming. We instead swallowed OOP principles like that of Java. But things are changing and Rust is designed to be powerful, not simple and easy-to-learn.

nice, really happy that it helped! and props to you for tackling a ray tracer, that's quite an undertaking!

i hope you'll succeed and i'll be really happy if you'll let us know!!! all the besttt

What do you use to draw a single pixel on screen ? Was interested to learn rust doing a raytracer, even a basic one who does not use the gpu at first

@@gaxkiller i use the ppm format, which just writes the rgb values of each pixel. Though I think you can use the image crate to convert to jpg/png

@@aditeya1024 Thx ! Ok so you write in a file, not on screen, perfectly fine but you cannot do "interactions" (move the camera, etc)

thanks so much for the kind words!

nice, glad you found it valuable!

They are not really interchangeable. Using "impl" is just syntactic sugar for a generic function, so as explained in the video the compiler will instantiate this function for each type that is used. This also means you cannot use it for example with a collection holding different types with the trait - for that you must use "dyn" and its virtual table (and that collection will also need to use fat pointers).

great point!

wow thank you so much for the support Jan!!! more to come!

nice, really happy you got something out of it!

thank you, glad you liked it!

nice! really happy the video helped you understand Rust traits!

Thank you! 🙏

thanks! more to come!

Thank you, glad you found it valuable!

thanks, really happy you liked it!

thanks for watching!

thanks for the feedback, we are always trying to make things entertaining while not being too obnoxious, sometimes that's a fine line to traverse!

thanks glad you got something out of it!

nice, really glad you got something out of the video, despite likely already being familiar with many of the concepts!

thank you!

wow thank you so much for your support!!!!

nice, love it when folks who already know about the video topic are still able to get value!

@@codetothemoon It's hard to find intermediate level content on Rust, so thank you for all the videos you make! I'm finding that going from being adequate at Rust to being good at it is a very long journey.

The editor is doom emacs.

thanks, really glad you liked it! I'm currently using DOOM emacs which I'm really enjoying at the moment. And I am also trying a new keyboard called a Corne - it's pretty amazing and I can't see myself going back at this point

@@codetothemoon do you have your doomemacs config shared somewhere? I tried to enable inlay hints but failed.

@@codeshowbr actually i don't believe I did anything special other than uncommenting (rust +lsp) in init.el, and I *think* also uncommenting "lsp" in the "tools" section

thanks for watching!

Thanks, much appreciated!

you could add a try_as_x() method to the trait, that in the default implementation returns None, but you can override it so it convers the type. like struct Foo; trait X { fn try_as_y(&self)->Option {None} } trait Y { fn try_as_x(&self)->Option {None} } impl X for Foo{fn try_as_y(&self)->Option {Some(self)}}} impl Y for Foo{ fn try_as_x(&self)->Option {Some(self)}}

@@PeterAuto1 It's just kind of awkward that I have to list out all the traits I want to be able to cast into, and then remember to override the cast function for every type that implements the corresponding trait. I had found some crates that apparently generate this boilerplate code with macros, but they don't have that many downloads, so I figured maybe I just shouldn't be doing that in the first place. But thanks for the tip anyway.

You could use trait downcast

i know this is an old comment, but there is std::any::Any in the standard library for this exact thing

@@homelikebrick42 Not quite. Any only allows casting to a concrete type. What I wanted was to cast a trait to another trait. For example, given a list of dyn Sensor, get all the items that implement the Thermometer trait, and then call a method from that trait. This is what is easy to do in C# and C++ but not in Rust. In Rust I have to add a method to Instrument with a default implementation (so that things that are not Thermometer don't have to implement it just to return an error), and then remember to override it where needed. It's kind of annoying. So now I'm trying to unlearn years of OOP so I can structure my code better to stop fighting against the language and avoid the problem altogether.

I see more and more "Integration-style Tests" in Rust and C/C++ code bases than Unit Tests, which I feel adds complications which cloud the purpose of the function and the tests, making the code less stable overall.

If you dive into rust for pratical uses you need to turn everything into async, so don't worry about that and do use async traits, also traits are really useful for mocking and testing and my company uses it all the time. But also makes so your struct has this contract (the trait) that tells you what it needs to implemento to be used for your porpose. This way you can always add new providers or mantain your code using this trait that tells you what your code needs to do. Here is one example: Imagine your service will hire a payments api service, and you build a Client for it that is able to call all the api's of the service. This endpoints are from your provider and there is no personal logic of yours. Now you need to not only call a endpoint, but multiple, or transform data before using it. This logic will go in your trait PaymentProvider or something like that. Another thing that can be useful for doing this is. Imagine that this Client struct is used by many services in your company. But your service only use a few of this endpoints. In your personal service trait you will only specify those endpoints that you need. My point is that this traits that are placed for mocking will be used for other reasons

@@JosephDalrymple About this integration-style tests I can say that usualy mocking is always the way for calling other services or providers and only testing integration with your database is useful, which always is easy to replicate for testing and doesn't make it unstable

​@@leviwebercosta8154 Unfortunately, spinning up, populating, and spinning down a database tends to be heavy, and shouldn't be done as a regular test of your codes functionality. These tests are great because they're End-To-End, but Unit Tests should make up the bulk of tests for any given application. Unit Tests typically test a single function at a time. But this can be difficult when async traits are not yet fully supported in Rust. While there are workarounds in the meantime, the problem in and of itself is already quite a complex one to solve, given the need to calculate lifetimes beyond what is currently done for structs with standard methods. Because of this, its not a trivial task to pivot from concrete async structs to dynamic async traits, especially when the only gain comes in the testing world. Most of what I've done to alleviate that is to create #[cfg(test)] and #[cfg(not(test))] implementations of my structs, which is a major pain, but it gets around having to deal with the immense overhead of introducing modular functionality just for testing purposes, when there isn't much else to gain. A more attractive solution would be the ability to define a mod.mock.rs or something to define the mock implementation of a struct for testing purpose. It's just not worth the overhead to introduce additional heap allocations simply to make testing more intuitive. That has unnecessary real-world implications on your application's performance.

@@JosephDalrymple I can only atest to how we do things at my job, whe usually use traits with async_trait library, and mock with mockall for unit testing. the services dont have any problem and no problems in performance.

thanks for watching! Keyboard is Corne v3 and IDE is DOOM Emacs

thanks, glad you liked the format!

doom emacs, monokai-classic

The supertrait bound only means that any type which implements Ambhibious is required to also implement WaterCapable and LandCapable, it doesn't do the implementation for you (not least because the implementation usually has functions in it which you are supposed to write). If you wanted to get an automatic implementation, you would not have "trait Ambhibious: WaterCapable + LandCapable" but instead have "impl WaterCapable for T { ... }", and this implementation would be used even if you only have "impl Ambhibious for Foo". But beware, if you do this then you will not be allowed to also write "impl WaterCapable for Foo", as this would result in two implementations of WaterCapable for Foo and rust doesn't like that.

Thanks, glad you found it valuable!

It's not VSCode, it's doom emacs. Not sure exactly what that is, but he said it in another comment.

I was wondering about this as well, I'm actually not sure!

@@codetothemoon impressive answer from chatgpt 😜: “The Rust compiler does not necessarily prefer dyn over impl in function signatures. The use of dyn and impl has different implications and may result in better or worse outcomes depending on the situation. In general, impl is suitable for specifying the exact implementation details of a type, while dyn is suitable for specifying a trait object that exhibits a certain behavior but whose exact implementation is not important. In function signatures, the use of dyn or impl may depend on the exact details of the function and the user's needs. If a function requires a specific type, and its implementation is important for the function, impl may be more appropriate. However, if the function requires a certain behavior that can be provided by multiple types, dyn may be more suitable because it provides the user with more flexibility in the choice of type. It is important to understand the implications of impl and dyn and base the choice on the specific needs of the situation. In some cases, the use of impl may result in better outcomes, while in other cases, dyn may be more suitable.”

thank you!

yeah, it would be an interesting test - i'd be shocked if nobody has posted the results of such a test yet...

Here is the test, if I got it right. Code: #![feature(trait_upcasting)] trait Surface { fn name(&self) -> &str { "unknown surface" } } trait Road: Surface { fn name(&self) -> &str { "road" } } trait Ice: Surface { fn name(&self) -> &str { "ice" } } struct Street {} impl Surface for Street {} impl Road for Street {} struct Glacier {} impl Surface for Glacier {} impl Ice for Glacier {} fn print(surface: &dyn Surface) { println!("Driving/Floating on {}.", surface.name()); } fn main() { print(&Street {} as &dyn Road); print(&Glacier {} as &dyn Ice); } Output: Driving/Floating on unknown surface. Driving/Floating on unknown surface.

Rust has single dispatch, an influence from C++. Bjarne has written at length about the difficulties of implementing multiple dispatch in a systems language.

I know this is an old question but I had to do sth similar lately. I just created an enum which variants contain the things with different traits. Then you can have a vector of this enum and can match over the enum to get to the desired element (subtype).

The curve ball was that you can't just use a trait as a parameter type, you have to specify 'dyn' or 'impl'. In most languages that's a decision that you don't have to make.

@@codetothemoonfair enough 👍

glad you liked it!

Not sure, I haven't done anything to deliberately make it faster. I am on a 1 year old M1 macbook pro, not sure if it's just because of the hardware

@@codetothemoon Thanks anyway - when I saw that compilation can be fast, I went searching for answers. It turns out that WSL2 was indeed my problem: accessing files from the NTFS side is quite slow. (It doesn't normally feel THAT slow, but I guess cargo or rustc accesses a LOT of files.) The solution is to move the source files to the Linux filesystem, or run the Rust compiler on Windows. VS Code can edit the files inside WSL, too. Btw, here's a hint for you, when you use rust-analyzer with VS Code: it shows the inferred types of local variables by default, but those can be hidden, as well as function parameter names. I find those to be spammy and super distracting, and I can get the same info if I need it, by hovering over the text :)

Some would argue that using polymorphism is "object oriented programming". I think the lines are a bit gray here.

“Objects” are no different than structs in Rust. You’ve got a memory region with a set of data in it. You’ve got a collection of operations the compiler will allow you to perform on that region. There is nothing special about objects.

The conversation behind classes and inheritance is different. But to associate “objects” with those ideas is IMO wrong.

indeed, I've been pretty happy with it lately

@@codetothemoon Your video on helix made me try it. Any plans to cover doom emacs in a future video?

thanks! I had been using VSCode just for the videos because it seemed like thats what most of the viewers are using, while using neovim behind the scenes. I switched to doom emacs and decided I really liked it, and haven't felt especially compelled to switch back to neovim. Shortly thereafter I decided to try using emacs in the videos as I figured it probably would't bother the VSCode folks - hopefully that is indeed the case 🙃 Thanks for the Ctrl-I tip, I'm constantly finding gaping holes like this in my knowledge of shortcuts!

@@codetothemoon only the code matters, not the editor you use, so keep using whatever editor you'd like, doesn't bother us

@@codetothemoon Makes sense. I think they've all looked great in the videos.

hah, you knew what was coming!

monokai

that is what dyn are

LOL that's a very good description of the approach Rust takes 😎

@@codetothemoon I'm not a rust developer but i just realized ive been subconsciouslly learning Rust through your videos. It now feels less intimidating, thank you so much for sharing your knowledge with us.

Lol 😂 I’m definately not one of those folks who is married to their editor, give me an alternative that has org mode and supports multiple fonts in the same buffer and I’ll consider switching 🙃

@@codetothemoon I definitely am one of those, but I've chosen the only good and bright side there is. 🤣

@@befosocial you're referring to Notepad I'm assuming? 😎

that fast forward makes me look like a competent typer!

It's not a class-based OOP language, but that's not an absolute requirement to be considered OO.

Rust's traits system *is* based on some OO ideas. I don't understand what you're trying to achieve by abstaining from Rust's premier construct for polymorphism. The language is clearly multiparadigm and you're only going to end up writing non-idiomatic code if you're in denial of that. Your comment about C++ also doesn't make sense. A project like STL was authored in C++ specifically because it had the best generics support you could get in a systems language at that time, even though STL's author preferred functional over the other paradigms. STL is also based on OO ideas, excluding inheritence. Of the OO ideas Rust took from C++, an STL inspired standard library and traditional oo single dispatch, which the traits system uses, come to mind. Rust is oo for the same reason C++ is, it just makes sense to encapsulation remaining state when you're done with the functional and pure part of your program. This is a natural evolution of systems languages that also target the application realm. I don't think there's any value in denying this.

The hive mind doesn’t know what they’re talking about at this point. What is special about an “object” in C++ vs a struct instance in Rust? Answer: nothing. An object is just a set of data in memory that can have certain operations performed on it. A struct instance if just a set of data in memory that can have certain operations performed on it. There is nothing special about “objects”. Using polymorphism has nothing to do with “object orientation”. Rust’s enums, traits, and generics all work with “objects” but those are premier features of the language. You can’t write any code without having complex structured sets of data and defined operations for them. These are objects. People see “OOP” and “Rust” in the same sentence and their brain cells dissolve.

thanks for the tip! i have some gaping holes in my knowledge of shortcuts. Getting tips like this is one of the things I like most about uploading videos 😎

What is your definition of object oriented?

nice!

Moses and Jesus both likely implement the Prophet trait, which presumably contains a teach method! They are certainly not polytheistic, but could be viewed as polymorphic...

@@codetothemoon 14 And the Word was made flesh, and dwelt among us, (and we beheld his glory, the glory as of the only begotten of the Father,) full of grace and truth. 15 John bare witness of him, and cried, saying, This was he of whom I spake, He that cometh after me is preferred before me: for he was before me. 16 And of his fulness have all we received, and grace for grace. 17 For the law was given by Moses, but grace and truth came by Jesus Christ. 18 No man hath seen God at any time; the only begotten Son, which is in the bosom of the Father, he hath declared him. (Jn.1:14-18) 39 Search the scriptures; for in them ye think ye have eternal life: and they are they which testify of me. (Jn.5:39) 46 For had ye believed Moses, ye would have believed me: for he wrote of me. (Jn.5:46) 45 Philip findeth Nathanael, and saith unto him, We have found him, of whom Moses in the law, and the prophets, did write, Jesus of Nazareth, the son of Joseph. 46 And Nathanael said unto him, Can there any good thing come out of Nazareth? Philip saith unto him, Come and see. 47 Jesus saw Nathanael coming to him, and saith of him, Behold an Israelite indeed, in whom is no guile! 48 Nathanael saith unto him, Whence knowest thou me? Jesus answered and said unto him, Before that Philip called thee, when thou wast under the fig tree, I saw thee. 49 Nathanael answered and saith unto him, Rabbi, thou art the Son of God; thou art the King of Israel. 50 Jesus answered and said unto him, Because I said unto thee, I saw thee under the fig tree, believest thou? thou shalt see greater things than these. 51 And he saith unto him, Verily, verily, I say unto you, Hereafter ye shall see heaven open, and the angels of God ascending and descending upon the Son of man. (Jn.1:45-51)

And the first beast was like a lion, and the second beast like a calf, and the third beast had a face as a man, and the fourth beast was like a flying eagle. (Rev.4:7) The four animals describe the four traits of Jesus :)

Thanks for the feedback! What else didn’t you like aside from the flashiness?