Hack and HHVM solves what is, IMO, the worst feature of the default PHP runtime environment[0] - and that is the superglobals. It wasn't mentioned in the post

Hack and HHVM solves what is, IMO, the worst feature of the default PHP runtime environment[0] - and that is the superglobals. It wasn't mentioned in the post from Slack, but default superglobals and the earlier register_globals design decisions are the worst and most impactful wart in PHP. Because it was designed as a templating language, the default web server interface, which is CGI - will auto-expose all variables in global scope, ex. echo $_POST['user_id'] PHP has a horrible reputation with security for this reason - we all know that somehow, somewhere, in almost every project someone is pulling in a user-controlled variable from a superglobal and they aren't escaping or checking it properly (since you can't be warned about it but the feature will work). Worse - and i've seen this a lot, even with Laravel, CodeIgniter, Cake, Symfony/Silex etc. you end up with these well structured projects that declare request classes, methods and variables etc. etc. but then sometime down the road a developer takes a shortcut in a method and pulls in a $_GET or $_POST inside a controller (usually because they don't know how, or aren't bothered to - changing all the related classes) - running around the default exec stack. I've seen this so often - because it's so easy to do it. The most common place is where a designer has built a frontend AJAX form. They now need to build a quick backend check, so they Google "php backend ajax username check" and they'll likely get a result like this one: http://stackoverflow.com/questions/29459183/check-username-availability-using-ajax http://stackoverflow.com/questions/29459183/check-username-a... where the 4th and 5th lines to the solution are: $username=$_POST['username']; $query="SELECT * FROM username_list WHERE username='$username' "; they copy that into a file called ajax_username_check.php and save it to the server - and they've now destroyed all that previous good work by opening up a very blatant and easy to find SQLi vulnerability. Their database will be on pastebin within a month. You can spot this type of vulnerability from the frontend because the URLs used in the AJAX calls don't match the URL router patterns for the rest of the app (ex. GET /user/username_check_ajax.php vs /user/check_user). In other languages you can't get that without using a standard library that will escape the values by default. Any solution you search for will always be a safe method to obtain the variable values by default. Some good news: Hack doesn't expose superglobals in strict mode: http://cookbook.hacklang.org/recipes/get-and-post/ http://cookbook.hacklang.org/recipes/get-and-post/ I'd strongly recommend that this is used in all PHP projects, since it strictly enforces variable access - even in cases where you're using a framework that is supposed to enforce it. IMO PHP missed a big opportunity with not removing superglobals in version 7 and enforcing an explicit safe request object much like other languages do. They likely wanted to avoid it because of the cluster of register_globals and magic_quotes from earlier versions. [0] I think it is important to distinguish PHP the language and PHP the runtime. PHP the language is now decent - having caught up with a lot of features (although I find it very verbose and harder to read) while PHP the runtime is undoubtably still a horrible runtime - hence HHVM