Whether it's a crash or not is independent of whether you even haven a monitoring system, an operations staff, or even if you run the program as a service or not.

Heck, your monitoring system could still notice the program exiting and call your operations stuff in Rust's case too.

And a user with sudo rights killing -9 a program you run might or might not send anything to your monitoring system -- but that wont be a crash either.

I think the important point the parent is trying to make is between a crash and a controlled exit, that is whether you get a stacktrace, things can be called to cleanup, etc.

Merely calling all the cases just "crash" would lose that distinction. It's like calling all vehicles "vehicles". Sure, it's accurate, but I want to know if it was a car, a motorcycle, a truck or whatever.

In Rust a panic brings down a single thread (unless you have it set to panic=abort, which is the case in firefox but not elsewhere).

Panics can also be "caught" like exceptions, though this is not something you're supposed to use to implement exception handling. The idea is that if you want to make your application robust you can catch these panics near the top and try to recover.

Often panics bringing down a single thread will bring down other threads that try to read messages from it and have declared that they will panic if that is not possible. (.recv().unwrap() is a common idiom).

So it depends on how you use it.

And "monitoring system" is assuming the context of a server side application.

Yes, but you also immediately know where it happened, what happened, and how to fix it.

That’s a massive improvement over alternatives