I really like your approach to Rust. Your videos are some of the most useful, especially for topics like structuring applications and crates, handling errors (really like your progressive error handling approach) and the more useful aspects of 'living' with Rust. Lots of channels do 'the features' of, or learning Rust. You really deal with living with Rust. I would say you should consider writing a book but then your RUclips channel is essentially your book. Well done, really good content.
I've been writing production-grade Rust code for about four years now. IMHO, this channel is highly underrated and is hands down (one of) the best for learning idiomatic Rust. Keep it up!
The descriptions on the module structure for the project, making certain modules or functions public, and the tie in with your recommendations on error handling are very helpful. Thank you for taking the time to make and share this information.
sooo good, id love to work in your code bases, sick of working with sloppy devs who don't care about any consistency. module system definitely takes getting used to but I am thankful for your examples I will rewatch a few times.
@@VonCarlsson The Error enum is as large as its largest variant. So, if nesting deep, sometimes using Box is advisable. But this could be seen as an optimization.
Very good practicies, I almost apply the same. One question, for the chainable setters, why do you prefer the consumable version instead of the mutable reference one ? ( "with_..(self, ..) -> Self" instead of "with_..(&mut self, ..) -> &mut Self" ?)
Both are valid ways, but I personally prefer the consuming pattern because of the symmetry in the return type between the constructors and setters. I find the owning style chain better, and I do not have to make an "exception" for a build vs. set step, and it's also compatible with the typestate pattern when I need it. So, the main downside is the extra "builder = ..." when doing a multi-stage build flow, but the overall net value is higher for my style of coding. But again, nothing is fundamentally wrong with the &mut self, so if it's a better fit for a library or a particular API, that's totally fine. For example, one scenario where I use the &mut self for setters (and might return &mut self as well) is for my extension trait.
In addition, conventionally, also in other languages, "with_.." returns a brand new object leaving the original unchanged (immutable), where "set_..." is used if you want to return the changed object (mutable). Also, note that "set_..." does not have to return anything, it can simply be used to change the original object (still mutable), but cannot be chained in this case.
@crazyingenieur3277 I might be missing something from your comment, but I am not sure that in Rust "with_... returns a brand new object" is common (especially in the context of chainable/builder patterns). In fact, if that were the case, in the case of "&mut self" style, it would be somewhat odd in the Rust world to have a "with_...(&mut self, ...) returning Self" (and in this case, &self would only be needed, but even then, it might be odd). Now, obviously, in the context of the consuming pattern, the given self instance is lost to the caller until it gets it back. But typically, the instance gets mutated inside the function before being returned to avoid unnecessary clone (some specific use cases might be warranted). So, my recommendation is that chainable functions follow the following patterns: - When &mut Self is the argument, return &mut Self. - When Self is the argument, return Self. I think this symmetry is very important to get the most of the Rust typing system and is very common in Rust patterns. Now, if there is a strong need to give a &self and return a brand new Self, then using "new_" as a prefix can be a valid option. Like "new_with_config(&self, ...) returning Self." But, I would argue that it could be better to just do ".clone().with_config(...)" (shorter, and more flexible as it's just a .clone() prefix beside all the other chainable functions). Note: The fact that other languages have different conventions is fine. Rust differs enough on the ownership front to warrant a "baggage-free" set of patterns for its constructors/builders/chainable function realm. Anyway, just wanted to clarify this in case it was not clear for some.
Great comment. Here is the context of the current approach. We could have the adapter as opt-in via the Rust feature, but the code variation per adapter is very small. Adding per-adapter features would bring more complexity for little value. Interestingly, when I started this library, I was using async-openai and ollama-rs, and I started this feature route. But, once I realized that I could, counterintuitively, simplify a lot of code and have more code reuse by going one level lower and talking to those APIs directly via their web protocols, the value of per-adapter features greatly diminished and could add unnecessary complexity. That being said, there might be some future features, specifically when talking to cloud provider services like AWS Bedrock variants. Those might require importing some external SDK, like some of the AWS Rust SDK crates, and those should be opt-ins. If I can find a way to implement it natively, that would be ideal. Otherwise, I would probably enable those families of adapters with a "with-aws" kind of feature. Hope that makes sense. Thanks for the note.
RustRover / IDEA also supports regions, just write a comment like // region foo, then later // endregion Things like functions, modules and enums automatically have “collapse” widgets.
I digged a bit and. It seems it is Rust Analyzer that's telling VSCode what's collapsible. So in a sort of nutshell, if you don't have Rust LSP extension, it's very likely you won't have region delimiter
I really like your approach to Rust. Your videos are some of the most useful, especially for topics like structuring applications and crates, handling errors (really like your progressive error handling approach) and the more useful aspects of 'living' with Rust. Lots of channels do 'the features' of, or learning Rust. You really deal with living with Rust. I would say you should consider writing a book but then your RUclips channel is essentially your book. Well done, really good content.
Thanks for the feedback. I like your “living with Rust” depiction. It is a good description of the intent of these videos.
I've been writing production-grade Rust code for about four years now. IMHO, this channel is highly underrated and is hands down (one of) the best for learning idiomatic Rust.
Keep it up!
The descriptions on the module structure for the project, making certain modules or functions public, and the tie in with your recommendations on error handling are very helpful. Thank you for taking the time to make and share this information.
Once again, some high quality content by Jeremy. What a goldmine these videos are...
I am a rust beginner, this kind of video is really helpful❤ Thank you so much! Looking forward to the part 2 and 3
Part 2 is already available. Link in the description.
I'm waiting for the following episodes ❤
Your videos make me love Rust more and more every time... Amazing job!
Music to my ears. Happy coding!
Amazing video as always. Great to watch. Thank you for the great Rust content!!
this is so good, we need the rest please
Yes, coming soon. Finishing the editing. Probably, hopefully, part 2/3 will be ready by tomorrow.
Can't wait for the next episode, so insightfull
sooo good, id love to work in your code bases, sick of working with sloppy devs who don't care about any consistency. module system definitely takes getting used to but I am thankful for your examples I will rewatch a few times.
Thank you! The animations on import and use got me hooked. Good job!
As always, I welcome every good practice tip ♥
Looking forward to the rest of this series - what’s your ETA for part 2 and 3?
This Friday is the part 2
thank you, super underrated. much love!
Great! I'm interested in more walkthrough videos that showcase well-crafted code. Does anyone have any additional suggestions for content like this?
Thank you so much for the quality of your contents
Doesn't grouping errors like that run the risk of bloating the size of the Result type?
@@VonCarlsson The Error enum is as large as its largest variant. So, if nesting deep, sometimes using Box is advisable. But this could be seen as an optimization.
great series idea. really useful stuff here
nice job Jeremy 👍
Love your videos
super duper helpful video.
Very good practicies, I almost apply the same. One question, for the chainable setters, why do you prefer the consumable version instead of the mutable reference one ? ( "with_..(self, ..) -> Self" instead of "with_..(&mut self, ..) -> &mut Self" ?)
Both are valid ways, but I personally prefer the consuming pattern because of the symmetry in the return type between the constructors and setters.
I find the owning style chain better, and I do not have to make an "exception" for a build vs. set step, and it's also compatible with the typestate pattern when I need it.
So, the main downside is the extra "builder = ..." when doing a multi-stage build flow, but the overall net value is higher for my style of coding.
But again, nothing is fundamentally wrong with the &mut self, so if it's a better fit for a library or a particular API, that's totally fine.
For example, one scenario where I use the &mut self for setters (and might return &mut self as well) is for my extension trait.
In addition, conventionally, also in other languages, "with_.." returns a brand new object leaving the original unchanged (immutable), where "set_..." is used if you want to return the changed object (mutable). Also, note that "set_..." does not have to return anything, it can simply be used to change the original object (still mutable), but cannot be chained in this case.
@crazyingenieur3277 I might be missing something from your comment, but I am not sure that in Rust "with_... returns a brand new object" is common (especially in the context of chainable/builder patterns).
In fact, if that were the case, in the case of "&mut self" style, it would be somewhat odd in the Rust world to have a "with_...(&mut self, ...) returning Self" (and in this case, &self would only be needed, but even then, it might be odd).
Now, obviously, in the context of the consuming pattern, the given self instance is lost to the caller until it gets it back. But typically, the instance gets mutated inside the function before being returned to avoid unnecessary clone (some specific use cases might be warranted).
So, my recommendation is that chainable functions follow the following patterns:
- When &mut Self is the argument, return &mut Self.
- When Self is the argument, return Self.
I think this symmetry is very important to get the most of the Rust typing system and is very common in Rust patterns.
Now, if there is a strong need to give a &self and return a brand new Self, then using "new_" as a prefix can be a valid option.
Like "new_with_config(&self, ...) returning Self."
But, I would argue that it could be better to just do ".clone().with_config(...)" (shorter, and more flexible as it's just a .clone() prefix beside all the other chainable functions).
Note: The fact that other languages have different conventions is fine. Rust differs enough on the ownership front to warrant a "baggage-free" set of patterns for its constructors/builders/chainable function realm.
Anyway, just wanted to clarify this in case it was not clear for some.
I think you can consider using #[cfg(feature = ...)] for different adapters
Great comment. Here is the context of the current approach.
We could have the adapter as opt-in via the Rust feature, but the code variation per adapter is very small. Adding per-adapter features would bring more complexity for little value.
Interestingly, when I started this library, I was using async-openai and ollama-rs, and I started this feature route. But, once I realized that I could, counterintuitively, simplify a lot of code and have more code reuse by going one level lower and talking to those APIs directly via their web protocols, the value of per-adapter features greatly diminished and could add unnecessary complexity.
That being said, there might be some future features, specifically when talking to cloud provider services like AWS Bedrock variants. Those might require importing some external SDK, like some of the AWS Rust SDK crates, and those should be opt-ins. If I can find a way to implement it natively, that would be ideal. Otherwise, I would probably enable those families of adapters with a "with-aws" kind of feature.
Hope that makes sense. Thanks for the note.
Which's the extension that lets you collapse regions?
It’s default to vscode. The trick is to have the region/endregoin comment markers.
RustRover / IDEA also supports regions, just write a comment like // region foo, then later // endregion
Things like functions, modules and enums automatically have “collapse” widgets.
I digged a bit and.
It seems it is Rust Analyzer that's telling VSCode what's collapsible.
So in a sort of nutshell, if you don't have Rust LSP extension, it's very likely you won't have region delimiter
You sound french ;)