I agree that you need to maintain supervisor hierarchies yourself because you know your application better than any other method I know of at the moment.
As for writing your own supervisors being impossible, the better word might be 'impractical'. It's clearly possible to have supervisors on the JVM given Erlang has a version on there (called Erjang). In no way is it practical to have it in Java the language, because the language's semantics simply don't match supervisors as well and they wouldn't be that useful there.
You're making the mistake of taking all features one by one and saying "sure, language X can do that" without considering how they would interact together or how well they would fit the language as a whole. What happens when you have a bunch of processes linked together and you kill some of them while they're modifying shared data or holding locks? What happens to objects that are shared and that need to be converted when doing hot code loading in some processes while you kill processes holding versions that are too hold (because they're seen as oprhans)? How do you deal with preemptive multiprocessing and scheduling when everything is done at the same level in a single language? Can you keep the soft real-time constraints with the garbage collector you currently have (Erjang had to drop that constraint)?
It's [relatively] easy to just make a Frankenstein out of features because of Turing completeness. Making a sensible ensemble out of them is a challenge and Erlang does it in a way I haven't yet seen in other languages. If you've got other languages that do it as coherently and have been battle-tested for decades, I'll be glad to add them to the list. Until then, you might as well classify your arguments in the same category as the eternal 'sufficiently smart compiler' in terms of practicality.
As for writing your own supervisors being impossible, the better word might be 'impractical'. It's clearly possible to have supervisors on the JVM given Erlang has a version on there (called Erjang). In no way is it practical to have it in Java the language, because the language's semantics simply don't match supervisors as well and they wouldn't be that useful there.
You're making the mistake of taking all features one by one and saying "sure, language X can do that" without considering how they would interact together or how well they would fit the language as a whole. What happens when you have a bunch of processes linked together and you kill some of them while they're modifying shared data or holding locks? What happens to objects that are shared and that need to be converted when doing hot code loading in some processes while you kill processes holding versions that are too hold (because they're seen as oprhans)? How do you deal with preemptive multiprocessing and scheduling when everything is done at the same level in a single language? Can you keep the soft real-time constraints with the garbage collector you currently have (Erjang had to drop that constraint)?
It's [relatively] easy to just make a Frankenstein out of features because of Turing completeness. Making a sensible ensemble out of them is a challenge and Erlang does it in a way I haven't yet seen in other languages. If you've got other languages that do it as coherently and have been battle-tested for decades, I'll be glad to add them to the list. Until then, you might as well classify your arguments in the same category as the eternal 'sufficiently smart compiler' in terms of practicality.