Seems like an interesting effort. A developer is building an alternative Java-based backend to Lemmy’s Rust-based one, with the goal of building in a handful of different features. The dev is looking at using this compatibility to migrate their instance over to the new platform, while allowing the community to use their apps of choice.

  • kattenluik@feddit.nl
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    11 months ago

    It’s a great and probably the best error system I’ve seen, instead of just throwing errors and having bulky try catch statements and such there’s just a result type.

    Say you have a function that returns a boolean in which something could error, the function would return a Result<bool, Error> and that’s it. Calling the function you can choose to do anything you want with that possible Error, including ignoring it or logging or anything you could want.

    It’s extremely simple.

    • uranibaba@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      11 months ago

      If I except a boolean, there is an error and get a Result, is Result an object? How do I know if I get a bool or error?

      • mea_rah@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        11 months ago

        You always get a Result. On that result you can call result.unwrap() (give me the bool or crash) or result.unwrap_or_default() (give me bool or false if there was error) or any other way you can think of. The point is that Rust won’t let you get value out of that Result until you somehow didn’t handle possible failure. If function does not return Result and returns just value directly, you (as a function caller) are guaranteed to always get a value, you can rely on there not being a failure that the function didn’t handle internally.

        • uranibaba@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          11 months ago

          If function does not return Result and returns just value directly, you (as a function caller) are guaranteed to always get a value, you can rely on there not being a failure that the function didn’t handle internally.

          The difference being where you handle the error?

          It sounds to me like Java works in kinda the same way. You either use throws Exception and require the caller to handle the exception when it occurs, or you handle it yourself and return whatever makes sense when that happens (or whatever you want to do before you do a return). The main difference being how the error is delivered.

          Java has class similar to Result called Optional.

          • mea_rah@lemmy.world
            link
            fedilink
            English
            arrow-up
            1
            ·
            11 months ago

            Yeah I suppose ignoring unchecked exceptions, it’s pretty similar situation, although the guarantees are a bit stronger in Rust IMO as the fallibility is always in the function signature.

            Ergonomically I personally like Result more than exceptions. You can work with it like with any other enum including things like result.ok() which gives you Option. (similar to java Optional I think) There is some syntactic sugar like the ? operator, that will just let you bubble the error up the stack (assuming the return type of the function is also Result) - ie: maybe_do_something()?. But it really is just Enum, so you can do Enum-y things with it:

            // similar to try-catch, but you can do this with any Enum
            if let Ok(value) = maybe_do_something() {
              println!("Value is {}", value)
            }
            
            // Call closure on Ok variant, return 0 if any of the two function fails
            let some_number = maybe_number()
              .and_then(|number| process_number_perhaps(number)) // this can also fail
              .unwrap_or(0);
            

            In that sense it’s very similar to java’s Optional if it could also carry the Exception value and if it was mandatory for any fallible function.

            Also (this is besides the point) Result in Rust is just compile-time “zero cost” abstraction. It does not actually compile to any code in the binary. I’m not familiar with Java, but I think at least the unchecked exceptions introduce runtime cost?

      • kattenluik@feddit.nl
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        11 months ago

        Here’s some examples written on my phone:

        match result {
            Ok(bool_name) => whatever,
            Err(error_type) => whatever,
        }
        
        if let Ok(bool_name) = result {
            whatever
        }
        
        if result.is_ok() {
            whatever
        }
        
        let whatever = result.unwrap_or_default();
        let whatever = result?;
        

        And there’s many other awesome ways to use a Result including turning it into an Option or unwrapping it unsafely. I recommend you just search “Rust book” on your search engine and browse it. Here’s the docs to the Result enum.

        • uranibaba@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          11 months ago

          Ah, so it is like a wrapper enum, ok contains the data type you want and err the error object?

          • kattenluik@feddit.nl
            link
            fedilink
            English
            arrow-up
            1
            ·
            11 months ago

            Exactly! The other wrapper enum I named (Option) is the same kind of concept but with Some(value) and None.