9 Rust Best Practices with Real Lib (part 1/3)

Поделиться
HTML-код
  • Опубликовано: 8 ноя 2024

Комментарии • 38

  • @nelsilicous
    @nelsilicous 2 месяца назад +3

    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!

  • @williamfletcher9932
    @williamfletcher9932 3 месяца назад +13

    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.

  • @DidierProphete
    @DidierProphete Месяц назад +1

    Once again, some high quality content by Jeremy. What a goldmine these videos are...

  • @craigrodger69
    @craigrodger69 2 месяца назад +4

    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.

    • @JeremyChone
      @JeremyChone  2 месяца назад +2

      Thanks for the feedback. I like your “living with Rust” depiction. It is a good description of the intent of these videos.

  • @terryhycheng
    @terryhycheng 3 месяца назад +2

    I am a rust beginner, this kind of video is really helpful❤ Thank you so much! Looking forward to the part 2 and 3

    • @JeremyChone
      @JeremyChone  3 месяца назад +2

      Part 2 is already available. Link in the description.

  • @crazyingenieur3277
    @crazyingenieur3277 3 месяца назад +4

    Your videos make me love Rust more and more every time... Amazing job!

    • @JeremyChone
      @JeremyChone  3 месяца назад +2

      Music to my ears. Happy coding!

  • @polares8187
    @polares8187 3 месяца назад +4

    Amazing video as always. Great to watch. Thank you for the great Rust content!!

  • @TarasShabatin
    @TarasShabatin 3 месяца назад +8

    I'm waiting for the following episodes ❤

  • @languageai-id
    @languageai-id 3 месяца назад +1

    Can't wait for the next episode, so insightfull

  • @Aucacoyan
    @Aucacoyan 3 месяца назад

    Thank you! The animations on import and use got me hooked. Good job!
    As always, I welcome every good practice tip ♥

  • @vacyyyy
    @vacyyyy 3 месяца назад +1

    this is so good, we need the rest please

    • @JeremyChone
      @JeremyChone  3 месяца назад

      Yes, coming soon. Finishing the editing. Probably, hopefully, part 2/3 will be ready by tomorrow.

  • @el_carbonara
    @el_carbonara 3 месяца назад +2

    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.

  • @meowsqueak
    @meowsqueak 3 месяца назад +1

    Looking forward to the rest of this series - what’s your ETA for part 2 and 3?

    • @JeremyChone
      @JeremyChone  3 месяца назад

      This Friday is the part 2

  • @Somfic
    @Somfic 3 месяца назад +1

    thank you, super underrated. much love!

  • @SniffleSneeze
    @SniffleSneeze 3 месяца назад +1

    Thank you so much for the quality of your contents

  • @mbczxaydbzrkmszj
    @mbczxaydbzrkmszj 2 месяца назад

    Great! I'm interested in more walkthrough videos that showcase well-crafted code. Does anyone have any additional suggestions for content like this?

  • @braverodger
    @braverodger 3 месяца назад

    great series idea. really useful stuff here

  • @emvdl
    @emvdl 3 месяца назад +1

    nice job Jeremy 👍

  • @VonCarlsson
    @VonCarlsson 3 месяца назад +1

    Doesn't grouping errors like that run the risk of bloating the size of the Result type?

    • @JeremyChone
      @JeremyChone  3 месяца назад

      @@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.

  • @PorkChopify
    @PorkChopify 2 месяца назад

    super duper helpful video.

  • @moquette31
    @moquette31 3 месяца назад +3

    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" ?)

    • @JeremyChone
      @JeremyChone  3 месяца назад +5

      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.

    • @crazyingenieur3277
      @crazyingenieur3277 3 месяца назад +1

      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.

    • @JeremyChone
      @JeremyChone  3 месяца назад +2

      @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.

  • @guzmonne
    @guzmonne 3 месяца назад +1

    Love your videos

  • @taquanminhlong
    @taquanminhlong 3 месяца назад

    I think you can consider using #[cfg(feature = ...)] for different adapters

    • @JeremyChone
      @JeremyChone  3 месяца назад +1

      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.

  • @antoniong4380
    @antoniong4380 3 месяца назад

    Which's the extension that lets you collapse regions?

    • @JeremyChone
      @JeremyChone  3 месяца назад

      It’s default to vscode. The trick is to have the region/endregoin comment markers.

    • @meowsqueak
      @meowsqueak 3 месяца назад

      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.

    • @antoniong4380
      @antoniong4380 3 месяца назад

      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

  • @Kabodanki
    @Kabodanki 3 месяца назад +1

    You sound french ;)