Use Hack instead of PHP

[haskellcamargo]

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).

:white_check_mark: 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.

:red_circle: 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

[sergiors]

What is the main goal of Quack Lang?

[joaolucasl]

I like the idea of using Hack instead of PHP. Hack itself is a much better language in several aspects. I think the compiler development can benefit from the type annotations, and also from collections like Enum. They are working on full PHP7 support now, but after that it will take its own path - which means a improved language will probably emerge, once detached from the PHP background.

Another point is that while Quack targets PHP, it is not bound to PHP forever, and HHVM's JIT might be a better option in the long run.

Are the plans still to use the current version of Quack and then dogfooding to build another version with LLVM or anything like that? If so, the problem of few machines having Hack won't be for long, since soon-ish there will be a binary version of the compiler.

[luizperes]

First of all, shouldn't we move this rfc to https://github.com/quack/rfc? We need to start having rfcs there someday xD Maybe we could do something like Swift and Ponny do.

Well, I don't think that we should use HHVM instead of PHP for now.

Reasons:

• As long as I am concerned, the PHP version of Quack will serve only as bootstrap, right? That means that changing it to Hack will not make any differences in the future.

• I am looking forward to writing Quack in Quack (I think that we should finish a stable version in PHP first and only then rewrite Quack using the stable Quack version written in PHP).

• Quack is already compatible with HHVM (meaning that we may use it on local versions [we can write a script that may do it for us]), while the opposite may not be true.

• We all (the current team) will need to setup new programming environments (I am being lazy, but it is a point).

p.s.: After writing all these points, I think that we could write scripts for choosing one (PHP) or the other (HHVM). How hard would that be? Does it run using <?php flags instead of <?hh? Sorry, I am just not that familiar with HHVM.