5 Essential Rust Design Patterns to Write Better Code

Writing maintainable and scalable code still requires good design patterns. In this video, we’ll cover five of the most essential software design patterns for Rust, showing how they work and when to use them.

📚Chapters
00:00 Introduction
00:13 Builder
01:07 Factory
01:56 RAII
02:59 Typestate
03:59 New type
04:35 End

#Rust #Programming #DesignPatterns

[nezudev]

I was never familiar with the builder pattern until I saw that many crates in rust/cargo use this pattern and instantly loved it. One of my favs

[AlyceIsFree]

For the typestate pattern, I would recommend using PhantomData<State>, and setting the default state = Closed, this will result in a more ergonomic api

[Mane]

Great video! With the builder pattern, it is common to return a different struct when calling `build()`, which represents the final, constructed object.

[abdullafaizov]

Great explanations! This is literally what rust is about. Static types and safe ownership model that allows checks at compilation. + polymorphism that makes your code clean and flexible. Moving from js to rust saved me hours in the long run. Its a little more difficult to write code in rust, but the compiler errors make sure you don’t make dumb mistakes and its so much easier to debug. If your rust code compiles, probably it will work as you expect the first time you launch your code, that is if your code logic is correct.

[PaulSebastianManole]

For the builder pattern, it's not just components that you can build with, it's also composing behavior. E.g. you can combine builder with strategy pattern for example.

[giriw]

I only occasionally use Rust at work, but thanks for sharing! It was well explained and really helped me understand Rust better

[alfianandi]

Wow thanks for the video Max! the Typestate is amazing to me

[LtdJorge]

With typestate, you don’t even need to use the generic type in a field (well, you put it in a PhantomData). You can also derive Default in your empty (except for PhantomData) struct, and in the return type of fn open() you put a File<Open>, to create your struct you can just call Default::default(). This way, the compiler figures everything out with type inference and you never have to mention the internal State or PhantomData<State>

[elikponblanou]

Very well explained. Thanks for the video Max.

[federicoagustinsawadyoconn]

Very good videos! What do you use to make the animations? I teach data structures so it would be great for me to know.

[irlshrek]

this video would pair well with the crate called `bon`! it's been a game changer for me

[akulij]

4:24 - btw, there is already exists Duration for time typization. Good example of new type pattern u suggested, thou

[DineshPatel-fpwl]

Nice cool videos. What do you use to make them and create the animations?

[manuelsopenaballesteros]

I would also give an example of monomorphism (static dispatch) for the second pattern

[tanuvishu]

Great video. Please keep up the good work.

[trombecher]

I think we should leave the factory pattern in Java. If you need a function that creates objects just put it in global space, or if you like in a module, because creating a unit struct type which will not even be instantiated is just a more complex module.

[enic-ma]

I like burgues and code! Why collegue didn't explain it that way?

[k.wakana]

I would like to get the full explanation of rust lifetimes and about subtle things and subtle errors from compiler. Id be so grateful if you could do such kind of video ❤

[pad]

Hi I am curious. Is it safe to just unwraping mutex in rust? How did you know that your program will run without crash?

[PaulSebastianManole]

The data has nothing to do with RAII. Your data still lives after the mutex closes. The only thing in your example that respects RAII and scope-based resource management, is the lock, i.e. the key, when that get out of scope, it runs its destructor which closes the mutex. But that is not the purpose of RAII.