3 ms·

100% of our web front end developers use Hack now. This has been an organic process of growth over the past year, by which I mean our engineers are using it bec

by bos 13y ago

100% of our web front end developers use Hack now. This has been an organic process of growth over the past year, by which I mean our engineers are using it because they like it and see value in it, not because there's someone standing over them with a big stick :-) The biggest learning step for our engineering teams was to treat type errors from Hack as actual logic errors. We have a collection of "linters" that provide advice on code style and other nice-to-have factors. Some people (quite reasonably) initially thought of Hack errors as lint-like stuff that it was safe to ignore, when in fact they indicate real logical inconsistencies in code.

wiremine 13y ago
> Some people (quite reasonably) initially thought of Hack errors as lint-like stuff that it was safe to ignore, when in fact they indicate real logical inconsistencies in code. Interesting, thanks! One followup: what has it been like from an ops perspective? Similar to PHP, or is there a better frame of reference?
- nbm 13y ago
  Can you rephrase your question about the ops perspective? Is there something in particular you want to know about?
  - wiremine 13y ago
    Sure. I guess I'm wondering how it compares to running plain old Apache/PHP in a production environment. Or, is it more like a Django/Rails stack? Does it use the same memory footprint as PHP, etc?
    - nbm 13y ago
      Facebook hasn't used plain old Apache/PHP in production for several years (HipHop for PHP was announced in Feb 2010), so it is hard to compare. HHVM is its own web server (although it supports FastCGI for easier use with existing infrastructure like nginx), and that's how we use it in production. It's hard to compare memory usage, except at scale, where it benefits from not having a whole bunch of interpreters (in different processes) running at the same time and some other benefits by using more appropriate types to store values through type inference.
    - SaraMG 13y ago
      On the scale of a single request (doing stuff from the command line), most benchmarks I've seen are about half the memory footprint. Obviously that's going to vary program to program ($data = file_get_contents("some2gbfile.txt"); is going to take 2GB, regardless), but for "normal usage" 1/2 looks fairly common. On a webserver, that goes further since HHVM is single-process/multi-thread, whereas PHP (in its typical setup) is multi-process/single-thread. This cuts HHVM's memory overhead much further. Yes, PHP can run multi-threaded, but it still has a number of instability issues in that mode.

by bos 13y ago

wiremine 13y ago

> Some people (quite reasonably) initially thought of Hack errors as lint-like stuff that it was safe to ignore, when in fact they indicate real logical inconsistencies in code. Interesting, thanks! One followup: what has it been like from an ops perspective? Similar to PHP, or is there a better frame of reference?

nbm 13y ago
Can you rephrase your question about the ops perspective? Is there something in particular you want to know about?
- wiremine 13y ago
  Sure. I guess I'm wondering how it compares to running plain old Apache/PHP in a production environment. Or, is it more like a Django/Rails stack? Does it use the same memory footprint as PHP, etc?
  - nbm 13y ago
    Facebook hasn't used plain old Apache/PHP in production for several years (HipHop for PHP was announced in Feb 2010), so it is hard to compare. HHVM is its own web server (although it supports FastCGI for easier use with existing infrastructure like nginx), and that's how we use it in production. It's hard to compare memory usage, except at scale, where it benefits from not having a whole bunch of interpreters (in different processes) running at the same time and some other benefits by using more appropriate types to store values through type inference.
  - SaraMG 13y ago
    On the scale of a single request (doing stuff from the command line), most benchmarks I've seen are about half the memory footprint. Obviously that's going to vary program to program ($data = file_get_contents("some2gbfile.txt"); is going to take 2GB, regardless), but for "normal usage" 1/2 looks fairly common. On a webserver, that goes further since HHVM is single-process/multi-thread, whereas PHP (in its typical setup) is multi-process/single-thread. This cuts HHVM's memory overhead much further. Yes, PHP can run multi-threaded, but it still has a number of instability issues in that mode.