This issue proposes a discussion about the pros and cons of using HHVM instead of PHP for Quack.
This description in meant to be up to date for every new argument. After everybody put their opinions on the table, we'll open to voting. Each member here designed has the power of 1 vote (including me).

✅ Pros

• Compatibility
  • 100% of Quack is compatible with Hack.
• Embed linter
  • About deprecated functions and code smells.
  • This could be a trigger for pull-requests.
• Abstraction and expressiveness
  • Hack has more operators, such as ?-> and |>, that would help us a lot on handling complex and nullable structures. It also has support for parametric polymorphism, what would a lot easier to model the abstract syntax tree and different communication protocols.
• Safety and legibility
  • We could use types to power intellisense, make the compiler avoid some of the classical runtime errors and easier to new contributors understand.
• Async programming
  • Hack supports natively async and await. This could help us on things that demand multiple processes. I've built and event loop for PHP in order to achieve this on REPL (a sort of workaround, but it works and doesn't require pthreads).
• Optimized data structures
  • Not only arrays on steroids, but efficient data strucutures, such as maps, typed arrays, vectors and pairs.

🔴 Cons

• Portability
  • The compiled binary would be Hack and it is a lot easier to find a machine running PHP than Hack
• Performance.
  • PHP 7 is faster than HHVM for Quack.

Who can vote

• @haskellcamargo
• @luizperes
• @ythecombinator
• @joaolucasl
• @sergiors
• @cuchi

What would change

• Rename all .php to .hh
• Change all <?php to <?hh
• Gradually fix all issues in hh_client