362
Sublinks Aims to Be a Drop-In Replacement for Lemmy (wedistribute.org)
submitted 2 years ago by to c/fediverse@lemmy.world
308 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] 5 points 2 years ago (14 children)

If you say the function should only recieve one argument and returns always boolean. It is predictable to only allow the wanted args and forces you to return a boolean.

For example in a less predictable programming language e.g. Python: I can do all above but python does not stop anyone to put more or less arguments to a function, or a developer not adding typehints or not complying to them and return a string instead of a boolean.

But i had it wrong rust is similar to java on that part.

But still it is a lot more popular and easier to start with. So there will be a lot more contributor to sublinks than lemmy ever had.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 14 child comments
    •
  • [–] 12 points 2 years ago (13 children)

    Well in that sense Rust is even more predictable than Java. In Java you can always get back exception that bubbled up the stack. Rust function would in that case return Result that you need to handle somehow before getting the value.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 13 child comments
    •
  • [–] -1 points 2 years ago (12 children)

    That i dont understand? How can it be a result that i need to handle? If its not correct than java will throw an error. ( As expected, shit in shit out )

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 12 child comments
    •
  • [–] 4 points 2 years ago* (11 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 11 child comments
    •
  • [–] 1 point 2 years ago (10 children)

    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?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 2 points 2 years ago (6 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 2 points 2 years ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 2 years 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?

  • permalink
  • fedilink
  • source
  • parent
  • [–] -2 points 2 years ago* (3 children)

    That's a kinda terrible way to do it compared to letting it bubble up to the global error handler.

    You can also use optional in java if you want a similar pattern but that only makes sense for stuff where it's not guaranteed that you get back the data you want such as db or web fetch

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 2 years ago* (last edited 2 years ago) (2 children)

    You can bubble up the Error with ?operator. It just has to be explicit (function that wants to use ? must return Result) so that the code up the stack is aware that it will receive Result which might be Err. The function also has defined Error type, so you know exactly which errors you might receive. (So you're not surprised by unexpected exception type from somewhere deep in the call stack. Not sure about Java, but in Python that is quite a pain)

    Edit: To provide an example for the mentioned db fetch. Typically your query function would return Result(Option). (So Err if there was error, Ok(None) if there was no error, but query returned no results and Ok(Some(results)) if there were results) This is pretty nice to work with, because you can distinguish between "error" and "no resurts" if you want, but you can also decide to handle these same way with:

    query()
  .unwrap_or(None)
  .iter().map(|item| do_thing(item))

    So I have the option to handle the error if it's something I can handle and then the error handling isn't standing in my way. There are no try-catch blocks, I just declare what to (not) do with the error. Or I can decide it's better handled up the stack:

    query()?
  .iter().map(|item| do_thing(item))

    This would be similar to exception bubbling up, but my function has to explicitly return Result and you can see in the code where the "exception" is bubbled up rather than bubbling up due to absence of any handler. In terms predictability I personally find this more predictable.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago (1 child)

    But like, what kind of error are you gonna handle that's coming from the DB, if it's something like a connection error because the DB is down, then you are shit out of luck you can't handle that anyway, and you probably shouldn't, not from the layer you are calling your DB from, that's a higher level logic, so bubbling Errors there make sense.

    and if it's an "error" like findById doesn't always return something, that's what the Optional pattern is for.

    what you have described to me seems like a worse version of the checked/unchecked exception system.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 2 years ago

    But like, what kind of error are you gonna handle that's coming from the DB, if it's something like a connection error because the DB is down

    I could return 500 (getting Error) instead of 404 (getting None) or 200 (getting Some(results)) from my web app.

    Or DB just timed out. The code that did the query is very likely the only code that can reasonably decide to retry for example.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 2 years ago* (last edited 2 years ago) (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •