1. You can implement supervisor trees in rust or python, but neither of them have a runtime that supports that out of the box and an exception handling system that works harmoniously with that runtime, so you'd have to implement that all yourself, and it turns out to be a non-trivial task.

2. erlang has a variety of type checks at a number of conceptual levels, so strongly recommend you go plow through something like https://learnyousomeerlang.com/ in order to improve your understanding here.

That's the basics. The next level is, what if you want one process dying to interrupt and trigger killing another process that is associated with it -- perhaps it's the parent in an rpc -- that's the easiest case (and trigger the correct exception message in the logs of both nodes)

Oh. And it's on the other side of a cluster.

Sure, you could do it in Python or rust. It won't be zero lines of code. You're probably gonna get it wrong.

Certainly, you can do most things in most languages.

Rust and Python don't come with supervision trees, so you'd have to build or find that. They also don't come with async messaging, especially not cross node async messaging, so you'd have to build or find that.

Building procsess linking and monitoring where the death of one process notifies or kills other processes and all of that is tricky, and I suspect you won't find that; so you'll have to build it, which is going to be tricky.

But even if you have all of that, now you're writing Erlang style in another language, and it's not idiomatic and people won't understand or like your code.

You can even build in hotloading. I did it (poorly) in Perl in the early 2000s without knowing it was available elsewhere, and I did it more recently in C with dlopen and friends. It makes your code look real funny though.

I also think you missed the ease of raising exceptions... ok = ... is very powerful and concise. You don't write a throw, you don't worry about what failure looks like, you just pattern match success, and if/when failure happens, you usually have what you need to figure out what when wrong and if it's better to do something else, it's easy to update your code (and you can hotload the update to the running system)

The Erlang way doesn’t require exception handling code because processes are isolated, so when one dies the runtime can clean up after it (reclaiming memory, file handles, etc.) as it knows what process owns what resources. Links and monitors make it possible to expand this to custom types of resources e.g. DB connections, locks, queues…

The idea is to implement error handling in the core (VM, supervisors, DB connection pool) while the vast majority of the code can just crash at anytime and not worry about closings its files or whatever.

I think the let it fails slogan is taken too literally, especially by people who don't use OTP.

You can handle errors and exceptions if you want, the supervisors etc are more here for the unexpected failures that happens for all sort of reasons in any software.

Sometimes it also hides bugs because your solution appears to work correctly;)