Sublinks Aims to Be a Drop-In Replacement for Lemmy

I genuinely could not give a shit about Rust

This is the kind of bizarre rhetoric I've come to expect from a Java dev so badly addled with Java-brain-rot that they don't even know how to write their own name anymore.

Rust and Java aren’t competing outside of Silicon Valley and Big Tech,

Keep telling yourself that but I'm not the only one here saying Lemmy and Rust has a lot more chance at success. Parts of Mozilla are written in Rust with a view to replacing all of the codebase in it. Parts of Linux and Linux drivers are being built in Rust. Small programs like Exa (ls replacement) in Linux are written in Rust. Google replaced Java with Go.

Rust, Go and others are taking over. People have seen the light. Those of us with enough cognitive function left in tact are making moves to languages that matter and away from Java.

You're right Java will always be around just like COBOL. In about two mainframes managed by two COBOL devs in the entire world.

It's sad to see you like this. Arguing for your own abuse and misery at the hands of a language that doesn't care about you.

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?

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.

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