sysv init!
All of my systems' processes are managed by it and have been for at least two decades.
Occasionally I do these periodic tasks as well, which are handled by a thing called "cron".
Yes this is sarcasm. There is a lot of wheel-reinventing done these days which is entirely unnecessary if you consider the long-forgotten "Unix philosophy".
myapp:234:respawn:/path/to/myscript
Regards.
I make sure I write processes that don't fail. This is done with tooling (valgrind, cachegrind, unit tests, integration tests) and testing (automated testing, experienced testers).
The whole process restart mechanism is a combination of string and sticky tape to abstract away the problem of half-arsed poorly written bits of functionality that crap themselves every few minutes.
I can and have written processes that stay alive for years (5 years 122 days pegged at 100% CPU being the record after which a reboot was required as the Sun Ultra 2 hosting it was replaced).
Please name one major, non-trivial network system software that has gone for 5 years, 122 days without a fault in production anywhere.
Engineers in other disciplines make best efforts not to fuck up. And then they accept that they, or others, will fuck up anyhow and they plan for that.
So do we. And so we should. Betting it all on Red 19 is a strategy of roulette, not serious work.
My point is that betting entirely on one strategy for mitigating faults is unnecessarily risky. Especially when additional levels of mitigation are easily installed and configured. In your other post you even point out a series of things that you do.
I don't see why process management is of a different kind.
Edit: removed unnecessary grandstanding.
I have written massively distributed systems which have an insanely high reliability requirement and it is really not the answer. I've been doing this for 25 years.
A more appropriate statement is:
Fail early and gracefully, recover always, expect failure.
Fail gracefully - don't allow assertions to take the entire process out. Don't allow the language to crash the process out.
Recover always - design your system for recovery and understand recovery conditions.
Expect failure - know where and when something is going to fail and handle it.
Fail fast, fail often results in nasty shit like processes hung in restart cycles etc.