The article complained that a Rust program can crash when you call `unwrap`—in fact, the author says that's their strongest critique. Python crashes when you call `sys.exit`, so it's no better.
Unfortunately I don't think their critique is really coherent—this is an absurd standard.
Other languages have some kind of exception mechanism so the crashing unwrap gets caught and handled, preferably sanely. Erlang in fact is written around the idea of expecting stuff to crash, and restarting the crashed thing when it happens.
This crash gets caught and handled too: the process exits, the kubernetes pod fails, and the deployment recreates it from scratch. Panicking like this is a request for the infrastructure to turn the whole service off and on again, which is sometimes the correct way to deal with transient failures. The problem here is that the infrastructure was restarting the service with the same bad config every time, causing a crashloop. It's a system design bug.
I have never once seen someone try to catch a NoneType error in Python or an abort()/assert() in C, at least outside of things like HTTP handlers that try to catch everything - which you can also do in Rust!
Unfortunately I don't think their critique is really coherent—this is an absurd standard.