But actual crashes are most likely due to memory unsafety; I’d be extremely surprised if the root cause was not found to be in a memory-unsafe language, though I doubt it’ll be in the URL parser.
Memory safe languages also have crashes, often uncaught exceptions, or explicit calls to abort() or similar functions (die, panic, etc...). Infinite recursion, and the resulting stack overflow is another common cause of crash that can happen in any language.
In fact, a crash (segmentation fault) is an exception. In theory, the program could catch it and try to recover from it, it is just that it is a terrible thing to do because you can't be sure of anything from now one.
In fact, letting the program crash is the basis of "offensive programming". This idea opposes the idea of defensive programming, where you try to be prepared for anything and try to do something sensible. In offensive programming, you crash when things are not as expected. For example, if you ask for the 5th element of a 4 element list, in the former, you return some kind of default value, in the latter, you crash with an "out of bounds" exception, or let a watchdog restart the system.
That's a weak statement: isn't Chrome is almost entirely written in C++? I suppose you mean it's a memory overrun or use are free. You're probably right, then.
But in Rust, something like this could happen too, if someone added a panic!, e.g. on parsing a domain name with an empty component, or failure to put the domain name in a certain (external) structure. If the URL is parsed again on start-up, the application would be bricked. Granted, it's much easier to find and solve.
I would guess that various parts of Chrome for Android, especially its UI, might be in a memory-safe language. But yeah, in hindsight my word choice was poor; I should have said a root cause of memory unsafety.
As for Rust, if we’re talking about outright crashes (which on reflection I’m not sure if we actually are because of laxness in the definition of “crash”—I retract my proffered extreme surprise), panicking isn’t that (unless compiled with abort-on-panic or if a destructor panics while unwinding)—panicking is controlled and can (except for the cases already mentioned) be caught.
To be sure, you can still brick the app in the described way with persisted data triggering exceptions or panicking, but there at least can still be a difference.
