Experimenting with HHVM at Etsy (opens in new tab)

The PHP library is (surprise!) sort of a mess when it comes to things that use the libc locale (which tend to offer no other way of switching locale or encoding), things that use the locale settings from the intl extension, things that respect the default_charset setting (and/or the input_encoding setting, output_encoding setting, or internal_encoding setting), and things that actually take one or more of these settings as arguments.

It ends up changing the output of icu-based libraries, localizing stuff like number formatting. Otherwise you're re-implementing that in userland code, which is likely to be much slower.

This is what caused me to abandon HHVM for plain ol' PHP around a year ago. I was running it in Docker containers and the memory leaks would regularly crash my containers if left unattended for more than a couple of days.

It was quite frustrating because I noticed some definite performance gains (e.g., ~2x faster page loads, etc.), but ultimately opted for PHP's stability.

The benefit to running all this in Docker is that I can swap HHVM back in relatively easily (unless it's changed really dramatically over the past 10 months or so). Your comment has me tempted to give it another shot!

Beyond HHVM, in fact, has oob compiler. We've opted to hold off until 7 is out - HHVM extension support is still patchy.

Isn't shared nothing a scalable architecture?

http://en.wikipedia.org/wiki/Shared_nothing_architecture

Anything that touches our production databases, mostly sharded mysql, needs to go through our php orm.

We do have other contained infrastructure that is written in some other languages like go and scala.

I was also curious about this. If the main traffic interface is bespoke, I'm sure Esty would investigate other solutions. It would make the most sense to also experiment with Bespoke since it's just an interface that talks to other APIs, likely without any business logic and a huge codebase. It orchestrates other APIs into 'views' for the consumer so you have one consolidated endpoint.

I'd personally be curious if they experimented with Go lang for this. Low memory, fast startup, fast at run. It makes more sense to use another language for bespoke than anywhere else in their stack, at least from my limited external viewpoint that is :)

I'm a little surprised that HHVM would make or break anyone's decision to use PHP, since I'd think that there are more important language design concerns and features that ought to figure before it came down to that... at least in a PHP-vs-Java sort of fight, anyway. Big questions like your preferred form of typing (strong/weak, dynamic/static/Hindley-Miller inference, etc), threading, ease of writing list comprehensions, whether you need to have functions as first-class objects, et cetera et cetera. Or the ability to hire developers who use that language.

Depends on what you're building, honestly.

I think that it's easy enough to get a site running entirely on PHP--well tested, well supported, architecturally sound, and rewrite services into <noninterpreted-language-of-choice> as you hit performance bottlenecks.

If performance is absolutely critical to your app, then you may consider writing everything in Java/Go/C++, but it's pretty brutal for doing templating and whatnot. Besides, once you generate the page, there's a good chance you're going to cache a good part of it anyhow!

IMHO: HHVM/Hacklang are cool and i appreciate Facebooks contributions to building a better PHP enviroment... but at the end of the day, it feels like someone trying to put a V12 engine in a golf cart. It's cool if you are already driving a golf cart, otherwise it's weird.

So if you have the chance to start fresh: choose Java or Go. Or anything else... (define "performance"?)

The development cycle with PHP/Hack is fast. You code, then press F5 in the browser and see result instantaneous. With other languages, a static compilation time of even just a few seconds is very contra productive and annoying. Writing less (redundant) code helps a lot with prototyping too (dynamic typing, optional static types). The documentation on php.net with comments on each page (from the community) is very good.

Node/IO.js and Go have their advantages, especially if one wants to use WebSocket.

Nowadays, half of the code is client side anyway (be it HTML5 JS (maybe with React/Angular) or mobile apps) - in such cases the server output and receives a lot of JSON. And then Node.js/Go/HHVM are about equal as good in benchmarks, at least in my personal benchmarks (10.000 -100.000 requests/s with Apache AB tool).

Go or Java is still faster than HHVM/PHP7. I'm writing my new project (Magento Go (wordplay) ;-) ) in GoLang.

HHVM is just a PHP JIT compiler. It's not a different language.

That is Hack.

PHPStorm supports xdebug and HHVM: https://youtrack.jetbrains.com/issue/WI-18817#comment=27-865...