Yet, the author of the article himself agrees with me:
"Yes, you need to create and maintain the chain of supervisors yourself."
> You cannot write your own supervisors in other languages.
Now, that is total nonsense. First of all, Turing complete is Turing complete, so your statement is wrong just on this basis.
Now if you want to argue that it's easier to maintain such a chain of supervisors in Erlang than, say, in Java, I'll just disagree. You spawn processes (lightweight processes) all the time in Java and monitoring their death is a few lines of code.
You just don't need the support of the JVM for that, and going further, I just don't see what JVM support adds for this particular functionality.
Hence my point that Erlang doesn't buy you much over traditional programming languages in that area.
Sorry - I call an Emacs skeleton function and use identical supervisors to every other supervisor. I have never written a line of supervisor code in 8 years of Erlang coding.
The Turing complete argument implies that representation is not important. Joe Armstrong has a great line for dealing with that red herring. He asks people to write an algorithm for doing long division with Roman Numerals. Guess what the representation of a number in Arabic numerals make alogorithms easy even though Roman Numerals are 'Turing complete'...
Having run an internet bank in J2EE with a budget of over $100m dollars and then built a clustered full stack in Erlang for under 1% of that I have the data to prove that your talking mince. Please bring your comparative costs to the table.
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.
Yet, the author of the article himself agrees with me:
"Yes, you need to create and maintain the chain of supervisors yourself."
> You cannot write your own supervisors in other languages.
Now, that is total nonsense. First of all, Turing complete is Turing complete, so your statement is wrong just on this basis.
Now if you want to argue that it's easier to maintain such a chain of supervisors in Erlang than, say, in Java, I'll just disagree. You spawn processes (lightweight processes) all the time in Java and monitoring their death is a few lines of code.
You just don't need the support of the JVM for that, and going further, I just don't see what JVM support adds for this particular functionality.
Hence my point that Erlang doesn't buy you much over traditional programming languages in that area.