I didn't discover the joy of writing Rust code until I stopped trying to make the language something it isn't.
  • nous@programming.devEnglish
    1·
    1 year ago

    Or do we use an Arc such that our dependent services hold onto an Arc>, allowing concurrent access of the owned resource?

    Arc is already heap allocated, there is no need or point in Boxing an Arc. They serve the same purpose except Box is single owner and Arc is multi owner. Box is not the only smart pointer that supports trait objects: Arc is also allowed, same goes for Rc and other smart pointer types.

    Though the answer to that question as it stands is: it depends. Both methods they suggest are valid approaches with different tradeoffs. Another is to just forgo trying to share a single field and share the whole object, ie have Arc or &Service instead. Or clone the whole thing between threads, or many other patterns that suite different needs. A lot depends on what this service is and how it needs to be passed around the application and how long it lives for. A lot of frameworks already give you good patterns for this.

    For instance axum has a way to pass around state to handlers, generally you pass ownership of the resource to axum and let it clone as required. Typically this means using an Arc> for things that are expensive to clone. Though a lot of types you share this way (like database connections) deal with that internally and so are already cheap to clone in these usecases.

    While we could have written this as a service where UserRepo is an injected value, doing so would introduce the complexities we’ve already explored

    Does it? OOP style methods are basically just syntactic sugar for the most part. You can largely interchange functions and methods all you want to. Also, pure functions does not mean to most people to what your example is showing. Typically a function is considered not pure if it modifies any of its arguments. So by taking a &mut as an argument you make the function not pure.

    Given that I can only assume you mean raw functions vs methods on types. At which point there is not as big a differences as they think. For instance, their example of

    async fn handle_session_completed(
    user_repo: &mut impl UserRepo,
    session: &CheckoutSession,
) -> anyhow::Result<()> {

    Can easily be written as (well, at least if you ignore the issues around async traits which is a technical limitation that is being worked on, for now the #[async_trait] macro helps a bit, and hopefully soon this will be solved at a language layer)

    trait UserRepo {
    async fn handle_session_completed(
        &mut self,
        session: &CheckoutSession,
    ) -> anyhow::Result<()> {

    And this form can even be called like a the former:

    UserRepo::handle_session_completed(&mut user_repo, &session).await

    There is little difference between a method on an type and a function that takes a argument to a type in rust. At least not in terms of how that author talks about them. Though I would lean towards the raw function here due to the async issues with traits. But in a lot of non-async contexts both are equally nice to use and would probably lean more on the trait/type method instead. More and more I just think of methods as type namespaced functions more than anything else, that is basically how you use them 95+% of the time.

    But yeah, overall don’t write any language like it is a different language. Same goes for trying to write java like it is C or python like it is rust. Learn the patterns of the language you are using.

  • Knusper@feddit.de
    1·
    1 year ago

    Wow, man, I forgot just how object-oriented Java is. You’ve got all these services pretending to run independently, except they’re not actually running asynchronously, and every service has a pointer to all the other services they need to talk to, leading to a huge tangled net of cross-dependencies. That’s why everything needs to be an interface, so you can mock it in tests.

    Rust is a lot more …tree-shaped, with the main passing data into functions which call other functions and those return data, which can be passed into the next function.
    Obviously, you can also build services running independently, but it’s usually done a lot more intentionally, by spawning own threads, passing around an (explicit) Arc, and then because you’re actually running asynchronously, you do need mutexes and such…

  • onlinepersona@programming.devEnglish
    0·
    1 year ago

    Rust requires a mindset shift

    That’s easier said than done. I find that there’s no clear vision of what “idiomatic” Rust is. With functional programming, it feels like there’s a strong theoretical basis of how to structure and write code: pure functions everywhere, anything unpure (file access, network access, input conversion, parsing, etc.) goes into a monad. TBF, the only functional code I write is in JS or nix and nix-lang is… not really made for programming, nor is there any clear idea of what “good” nix code looks like.

    Rust however… are Arc, Box, Rc, async, etc. fine? match or if/else? How should errors be handled? Are macros OK? Yes, the clippy linter exists, but it can’t/won’t answer those questions for you. Also the fact that there is no inheritance leads to some awkward solutions when there is stuff that is hierarchical or shares attributes (Person -> Employee -> Boss -> … | Animal -> Mammal-Reptile-Insect --> Dog-Snake-Grasshopper). I haven’t found good examples of solutions or guidance on these things.

    My rust code still feel kludgy, yet safe after a year of using it.

    • nous@programming.devEnglish
      1·
      1 year ago

      Rust however… are Arc, Box, Rc, async, etc. fine?

      Yes, these are all fine to use. When you should use them depends on what you are doing. Each of these has a usecase and tradeoffs associated with them. Rc is for when you need multiple owners to some heap allocated data in a single threaded only context. Arc is the same, but for multithreaded contexts (it is a bit more expensive than an Rc). Box is for single owner of heap allocated data, async is good for concurrent tasks that largely wait on IO of some sort (like webservers)

      match or if/else?

      Which ever is more readable for your situation. I believe both are equally powerful, but depeding on what you are doing you might find a simple if let enough, other times a match makes things a lot more succinct and readable. There are also a lot of helper functions on things you often match on - like Result and Option that for specific situations can make a lot more readable code. Just use which ever you find most readable in each situation.

      How should errors be handled?

      This is a large topic. There is some basic advice in chapter 9 of the book though that is mostly about Result vs panic. There are also quite a few guides out there about error handling in rust in a broader sense.

      Typically they suggest using the thiserror crate for errors that happen further from main (where you are more likely to care about individual error variants - ie treating a file not found differently from a permission denied error) and the anyhow crate or eyre crate for errors closer to main (when you are dealing with lots of different error types and don’t care as much about the differences as you typically want to deal with them all in the same way when you are near to main).

      Also the fact that there is no inheritance leads to some awkward solutions when there is stuff that is hierarchical or shares attributes (Person -> Employee -> Boss -> … | Animal -> Mammal-Reptile-Insect --> Dog-Snake-Grasshopper).

      I have rarly seen a system that maps well to an inheritance based structure. Even the ones you give are full of nuances and cross overs that quickly break apart. The classic animal example for instance falls flat on its face so quickly. Like, how do you organise a bird, a reptile, a dog, a fish and a whale? You can put the whale and dog under mammal, but a whale shares a lot of things with the fish, like its ability to swim. Then think about a penguin? It is a bird that cannot fly, so a common fly method on a bird type does not make any sense as not all birds can fly. But a penguin can swim, as can other birds. Then just look at the platypus… a mammal with poison spurs that swims and lays eggs, where do you put that? Where do you draw the lines? Composition is far easier. You can have a Fly, Swim, Walk etc trait that describe behaviour and each animal can combine these traits as and when they need to. You can get everything that can fly in the type signature, even if it is a bird, a bat, or even an insect. Inheritance just cannot do that with the number of dimensions at play in any real world system.

      IMO it is simpler and makes more sense to think in terms of what something can do instead of what something inherits from.

      • anlumo@feddit.de
        0·
        1 year ago

        I recently caught myself trying to do traits in an OOP language. Failed spectacularly of course.

        But it would be so much easier to read…

  • The Cuuuuube@beehaw.orgEnglish
    0·
    1 year ago

    Java devs have some of the worst habits when they learn a new language. Why create a global variable for a setting in python when you can instead wrap that global variable in a Singleton class that makes using it no safer, and far more complicated

    • Jummit@lemmy.one
      0·
      1 year ago

      Actually, I like encapsulating global state in a structured and documented construct. But I guess I could see Java developers going overboard with abstraction in an imperative language.

      • Knusper@feddit.de
        0·
        1 year ago

        I think, the point is that in Python (like Rust) that construct is a module. In Java, a module does not exist in that sense. You put everything into classes in Java and static classes, i.e. singleton objects, are what you use instead of modules…