Think of the security implications of allowing anyone to run any language on their server. It doesn't matter if it's PHP, Ruby, or C++, since they all allow shell and filesystem access, unbounded recursion, and all the other goodies that make sandboxing interesting.
The trick would be to run PHP as a command-line scripting language, just like the others.
Afaik, the only (reasonably common) languages with good sandboxes are Tcl and Java. Like they said above, they're the ones building the sandbox, not the language.
i'm not exactly sure what he's talking about, but there's 2 things Lua has here. one is that the language is functional, so you can replace, alter, or remove the dangerous functions. the other is that you can specify the variable 'environment' of a function with a table (Lua's hash.) so you can construct its environment in an 'opt-in' basis and know for sure everything you're allowing the function to do is safe. and of course these things would be meaningless if built-in functions didn't behave like user functions
Untrusted Java web start applications and Java applets can't do anything that could harm the real operating system. We had to buy and keep on renewing an expensive code-signing cert so our app could save a local file.
Every once in a while, a security researcher claims to have gotten untrusted bytecode to run outside the boundaries of the sandbox.