[daleharvey]

> 1. Binaries: this isn't really an issue. We ship the JVM with anything that we do in Java. Unzip, run, done. Go is probably ideal there but it doesn't support embedded resources without some hideous hacks so you're still going to be deploying more than just a single binary in a lot of cases. CLR is pretty good at this as well.

Not sure you read / understood what that point was about, due to its native binary types, tail recursion and pattern matching make dealing with binaries easier in erlang than most other languages

As far as most of the other points, you are mostly agreeing with the statement "nothing is impossible with other languages compared to erlang, but its better designed for this"

PHP does not so long process thread supervision (I mean it can but close to 0 people use it that way), Being able to inspect running processes is useful as well as the fact google is helpful, the JVM's entire ecosystem isnt based around a let it crash concurrent process isolation philosophy and java in particular is one of the worst offenders at having to ember error handling code at almost every point of your application logic

[cowabunga]

Yes thank you for the clarification.

My point is more that regardless of the syntax, runtime or approach, the same outcome is possible without having to enter a risky niche.

PHP does nothing, but if you throw it in a prefork MPM module in apache, it does that.

Sure we don't let it physically crash and we handle the exception at the base of the thread and decide what to do, but the outcome is the same. Java error handling is absolutely fine and in some cases, far less painful that the "err" semantics of Go.

[platz]

The difference is that Erlang decouples the handler of the exception (the supervisor) from the caller.

In most other languages, the caller is forced to deal the the exception, which litters the responsibility to resolve the exception across all consumers.

This is qualitatively different from erlang