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.

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.

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

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.

Predictable in what sense?

The example even used unwrap_or_else where they should use unwrap_or. Then it uses std::i64::MIN as fallback value where they could use something like 0 that would be a better example and honestly make more sense there.

let parsed_numbers = ["1", "not a number", "3"]
    .iter()
    .map(|n| n.parse().unwrap_or(0))
    .collect();

// prints "[1, 0, 3]"
println!("{:?}", parsed_numbers);

Even without trimming this to something less convoluted, the same functionality (with different fallback value) could be written in more readable form.

Obviously in the context of the page something like this would make way more sense:

maybe_number.unwrap_or(0)

Or perhaps more idiomatic version of the above:

maybe_number.unwrap_or_default()

Is that Rust? Assuming a is an Option (which would be close approximation of OP’s nullable type) and assuming b is not null, then this would be closer to the original idea:

a.unwrap_or(b)

It returns value of a if it’s not None rather than Option.

I don’t have much experience with TS, but in other strongly typed language it goes even further than string vs number.

For example you can have two numbers Distance and TimeInSeconds and even though they are both numbers, the type system can make sure that you won’t do distance+time.

It can also let you do distance/time and return Speed type.

It will prevent many logical errors even though everything is technically a number.

I’m not sure where this idea of high profile target comes from. The sim swap attack is pretty common. People just need to be in some credentials leak DB with some hint of crypto trading or having some somewhat interesting social media account. (either interesting handle or larger number of followers)

There are now organized groups that essentially provide sim swap as a service. Sometimes employees of the telco company are in on it. The barrier to entry is not that high, so the expected reward does not need to be that much higher.

Yeah it’s pretty amazing system all things considered. It’s kind of as if 8-bit home computer systems continued to evolve, but keep the same principles of being really closely tied to the HW and with very blurry line between kernel and user space. It radiates strong user ownership of the system. If you look at modern systems where you sometimes don’t even get superuser privileges (for better of worse) it’s quite a contrast.

Which is why it reminds me of Emacs so much. You can mess with most of the internals, there’s no major separation between “Emacs-space” and userspace. There are these jokes about Emacs being OS, but it really does remind me of those early days of home computing where you could tinker with low level stuff and there were no guardrails or locks stopping you.

GNU Hurd is going to be mainstream any minute now.

I couldn’t help but think of Emacs when I was reading A Constructive Look At TempleOS. It’s like TempleOS that is actually finished, it just lacks kernel.