
The Future of HHVM - mwpmaybe
http://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html
======
TazeTSchnitzel
Given HHVM is already being dropped from PHP packages because of its lagging
compatibility, announcing that they're not targeting PHP compatibility any
more might be the nail in the coffin for HHVM (and thus Hack) as a viable
“upgrade” from PHP for _existing_ codebases.

I mean, it's great that Hack will work for new Hack code and existing Hack
codebases, but there aren't a lot of those. It makes sense for Facebook — why
waste your efforts on maintaining part of your runtime that you don't need? —
but I wonder if this will consign HHVM to irrelevance in the long term. Maybe
Hack is a compelling platform for new code, but then, why use this obscure
proprietary Facebook thing that's a bit better than PHP when you could use any
of the numerous other languages out there that are also better than PHP but
have much better ecosystems?

Personally this makes me sad because I wanted to see a standardised, multiple-
implementation PHP language. Facebook did, even. They paid someone to write a
spec: [https://github.com/php/php-langspec](https://github.com/php/php-
langspec)

Maybe someone will write a new PHP implementation to take that idea forward.
Or maybe we'll be stuck with Zend forever.

The future is strange.

~~~
muglug
It makes me sad that, as a Mac-based developer, installing & updating HHVM
takes half an hour (via Homebrew). I imagine that has taken the wind out of
many people's sails, when contemplating migrating/updating codebases to HHVM's
(superior) syntax.

~~~
fredemmott
Sorry, I know this is a pain; I'm hoping to fix it by the end of the year
(along with bringing back nightly debs, and supporting more recent versions of
debian/ubuntu). For homebrew build times, there's
[https://github.com/hhvm/homebrew-
hhvm/issues/5](https://github.com/hhvm/homebrew-hhvm/issues/5)

In the short term, docker works rather nicely.

------
muglug
HHVM & Hack solved two big problems that made PHP difficult for Facebook and
other large companies with large existing PHP codebases: Speed, and the lack
of type checking

Now the PHP ecosystem is more mature – PHP 7 eliminated the speed differences
between HHVM and PHP, and a bunch of static analysis tools find 95% of the
bugs that HHVM's typechecker finds.

It makes sense that this would be an inflection point for the future of HHVM.

I hope that more features from HHVM make it into PHP core – especially
property types and generics – because, whatever FB decides to do with HHVM,
PHP is here for the long-haul.

~~~
jimktrains2
> HHVM & Hack solved two big problems that made PHP difficult for Facebook and
> other large companies with large existing PHP codebases: Speed, and the lack
> of type checking

At what point do you stop using the hammer to put in a screw and just use a
screwdriver?

~~~
muglug
When the cost of buying screwdrivers for your entire workforce would likely
bankrupt the company.

~~~
jimktrains2
I'm not sure what you're analogy is here. You wouldn't switch every nail to a
screw in the same moment.

~~~
muglug
Right, but you're still investing time in doing that switch. No matter which
way you cut it, you're still replacing every single nail.

"We'll just update as we go", you say. That's fine, but it means that some
parts of the house – normally the oldest and most integral to the entire
structure - will use nails for years to come. And your developers will need to
be trained in both hammers and screwdrivers to be able to work on the house in
totality.

~~~
jimktrains2
Sure, but if those nails are also causing structural instability, then it
might be prudent to do the investment. It seems now, no one will be using your
type of nail anymore either, so now you have to have them custom made at
expense.

~~~
cwyers
Sometimes those nails are doing just the opposite, they're holding the
foundation together, and if you try and pull them all out the whole thing
might collapse.

~~~
VeejayRampay
This is why I use Krazy Glue for everything, so I don't have to think about
what's the nail, the screw and the hammer in this long-winded analogy about
PHP and its shortcomings.

------
rrdharan
This is fascinating. It's a well-written post and their plan makes sense to
me, but I imagine there's a tough choice ahead for framework authors (the
Laravels and Drupals of the world) about whether they want to fork their
communities, stay with PHP7, or try to target both with the same codebase (in
the near term or long term)?

At any rate at least the fact that the HHVM folks are communicating the
strategy effectively and transparently should help everyone involved make
reasonable decisions.

~~~
HugoDaniel
That and PATENTS:

[https://github.com/facebook/hhvm/blob/master/hphp/hack/PATEN...](https://github.com/facebook/hhvm/blob/master/hphp/hack/PATENTS)

~~~
zimbatm
If Facebook had released the code under BSD then nobody would have complained.

But this basically gives a BSD plus patent grant, and reverts to BSD if there
are any patent litigations. And now people are complaining.

~~~
s73ver_
Because it is them saying, "We can take all of your patents, but if you sue us
for it, then you don't get to use this."

~~~
jbergens
IANAL. I think that is a common misunderstanding of the clause. If you sue
them for react patents you can still use HHVM, or vice versa.

[https://medium.com/@dwalsh.sdlr/react-facebook-and-the-
revok...](https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revokable-
patent-license-why-its-a-paper-25c40c50b562)

------
bepotts
How is Hack? Has anyone built anything with it and would like to share their
thoughts? How's the HHVM community?

I've always thought that PHP was an underrated language that got a bad rep due
to whacky design choices and PHP developers being seen as "less skilled" (a
stereotype I know, but it is prominent) than others. Object Oriented PHP and
frameworks like Laravel were a nice change of pace in my opinion, and there's
plenty of good PHP coders out there if they had the right experience and stuck
to a good coding guideline.

Alas, I confess I stepped away from PHP due the stereotypes against it, but
HHVM always seemed promising. I haven't heard much about it over the years
though.

What's the toolchain for HHVM?

~~~
kmavm
I'm chief architect at Slack, and we migrated to Hack from PHP 5 throughout
2016.

The toolchain for HHVM is all installed as a single big deliverable, which
gives you the language engine and supporting runtime libraries itself, an in-
address-space web server (Facebook's Proxygen), a debugger in the form of hhvm
-a, and the Hacklang toolchain accessed via hh_client and appropriate
editor/IDE integrations.

I share your intuition that there is actually a glittering core of "stuff-
that-makes-you-successful" hiding in the incidental complexity of PHP, and we
wrote this blog post trying to put some substance behind that intuition:
[https://slack.engineering/taking-php-seriously-
cf7a60065329](https://slack.engineering/taking-php-seriously-cf7a60065329)

~~~
sneak
Wouldn't it make more sense to take the parts of the PHP runtime environment
that enable rapid prototyping and figure out how to implement them in a
language that has a working == operator rather than trying to graft type
safety on a language that has both strpos() and str_rot13()?

Remember BML, bradfitz' attempt to do this with Perl?

I would love to see someone do something similar for Python.

~~~
Can_Not
> a language that has a working == operator

== has always been working in PHP. I know maybe that optional type coercition
trips up some noobs occasionally before they made any effort to learn the
language (hint === doesn't coerce types for equality), but how low effort does
a complaint have to be?

Type coercition is actually pretty cool when you're not really sure what the
browser or client is about to http at you and you just want it to work. It's
much better than crashing at runtime because '12' isn't a number. If you're
input isn't sane, throw an exception or use a validation library.

Now if we're talking about a good type system that can be enforced at compile
time like rust, Scala, etc. Sign me up. But if it's run time, it's run time,
we gotta keep going.

~~~
sneak
> It's much better than crashing at runtime because '12' isn't a number.

something something yell at you for breaking their door

------
ryangordon
Here's the interesting thing about all this; HHVM will always be developed
because it's important to Facebook's bottom line and Open Source because it
only benefits them to keep it out there and have other people testing it and
improving on it.

Now that they're getting rid of direct PHP support, HHVM is only going to get
better. This will unlock a whole host of language improvements that HHVM
couldn't otherwise make.

HHVM is faster relative to PHP now, and it will only get faster with these
changes. Typing is an important part of making JITed code fast and unless PHP
ever decides to fully add it, it will never have the potential to catch up.
This is important to PHP-based companies as they grow and want to optimize on
cost and development efficiency.

Undoubtedly, this split will be painful initially for those of us who are
bought into the symbiosis of the HHVM and PHP ecosystem together. How painful
it is to split will just be a question of where members of the PHP community
want to go (or both). The nice thing is that converting something from PHP to
HHVM isn't terribly hard; not anywhere near like converting from PHP to
Golang. For HHVM, it's mostly just adding type annotations.

~~~
nkozyra
> HHVM is faster relative to PHP now

While this is probably still true[1], it's certainly less of a concern now
than it was with 5.x. Would (often negligible) performance boosts be enough
for someone with a 5.x PHP codebase to choose Hack over PHP 7.x? I can't see
that for most cases.

[https://kinsta.com/blog/the-definitive-php-7-final-
version-h...](https://kinsta.com/blog/the-definitive-php-7-final-version-hhvm-
benchmark/)

------
sunseb
I'm excited! :)

PHP is IMHO the most productive and easiest platform for web development:

\- a request

\- a response

\- templating

\- no shared stated

And that's it! But the language syntax has so many quirks. So it's cool if
Hack redesign the language and make it more beautiful and consistent. Many
developers switch to Ruby or Python because these languages are better
designed. I think Hack could attract a lot of these developers who want more
beauty in the tools they use.

~~~
dna_polymerase
Oh boy they really got you!

Have a look at Python & Flask! There is nothing easier than that!

~~~
geofft
Flask is really good (and my preferred web framework, and full disclosure, I
have forgotten how to write PHP), but it fails very badly at "no shared
state," and depending on what GP meant by "a request" / "a response", it fails
at that too. A Flask process handles an indefinite number of requests and
responses; the built-in server handles them serially, and doing otherwise
brings in either threads (and shared state) or multiple processes.

The Slack article posted elsewhere in these comments
[https://slack.engineering/taking-php-seriously-
cf7a60065329](https://slack.engineering/taking-php-seriously-cf7a60065329) has
some excellent arguments about why PHP's approach is different in interesting
ways.

------
ankyth27
Parse, react and now this. Why would I now learn any new Facebook tech?

~~~
cdelsolar
what happened with React?

~~~
hibbelig
BSD+Patents license.

------
maxpert
I am way less sad about HHVM now (specially after React license debacle). I
think Facebook now has opportunity to think about this fork as a fresh take on
PHP and maybe make the language awesome both from syntax/performance
perspective. I don't think living with a weird hybrid with current language
landscape is an option.

------
philippz
Sad. Facebooks involvement by utilizing PHP and pushing the language by
extending it was a good sign for the PHP community. Would have loved to see
that they align with PHP7 or even further, push their engineers into improving
PHP itself. PHP has such a huge ecosystem. I wouldn't risk to bet on Hacks
future.

~~~
COil
Agree, that's a pity. Instead of having one top language, we will have 2 "now-
incompatible-great-languages".

------
pbiggar
> Eliminating references. PHP references have unusual semantics, where the
> function specifies the binding of parameters with no indication at the
> callsite.

I feel like I called this one in [https://circleci.com/blog/critiquing-
facebooks-new-php-spec](https://circleci.com/blog/critiquing-facebooks-new-
php-spec):

> This is interesting because they’re changing the definition of the language
> through a sort of back-channel. They’re allowing breaking changes by
> effectively deciding that other implementation choices are equally valid.

> I’ll give you an example, which I’ll get into more below. There’s a little
> known bug in the Zend engine around copying arrays that contain references.
> IBM wrote a paper about this bug in 2009. Basically, this bug was necessary
> in Zend to make copying arrays fast, and IBM figured out a way to do it in a
> way that was actually correct, for only a 10% performance penalty.

~~~
smsm42
I get why they want to get rid of references. If I would be designing PHP from
scratch, that's probably the first thing I'd do - most hard to fix bugs in the
engine and most security woes of features such as unserialize() stem from
references. Unfortunately, _TONS_ of code uses them, and there are some data
structure things that would not work without it unless alternative solution is
provided. So it could not happen in PHP. But it'd be interesting to see how it
works for Hack.

~~~
fredemmott
we're currently leaning towards out/inout parameters, with copy semantics, not
byref (and in most cases, we'll probably be able to optimize away the copy);
not certain yet though.

~~~
smsm42
Would be nice to hear what comes out of it and how it works!

------
dcgudeman
I wonder what this means for wikipedia? Will they be migrating to a hack only
stack now?

~~~
zeitg3ist
MediaWiki runs on more than 25k websites [1] other than Wikipedia, so I don't
see them switching to Hack only.

Also, I run a pretty big MediaWiki site and the last time I tried moving
everything to HHVM (~6 months ago, I think) stuff appeared to be working
initially but randomly broke from time to time (probably because of Scribunto
or some other extension; couldn't manage to pinpoint the exact reason). PHP 7
didn't give me any problem at all; it's fast enough (way faster than PHP 5)
and most pages are served by the Redis cache anyway. I suspect that Wikipedia
will consider a move back to PHP, they're moving the most expensive logic to
Lua modules anyway...

[1]
[https://wikiapiary.com/wiki/Main_Page](https://wikiapiary.com/wiki/Main_Page)

------
foxfired
I think HHVM was equivalent to what jQuery was to JavaScript. jQuery forced
JavaScript to be better, and the better JavaScript becomes, the less jQuery is
needed.

So if we get to a point where HHVM is completely irrelevant, it simply means
"Mission Accomplished".

~~~
VeejayRampay
In terms of language, jQuery didn't innovate in anything though. It was a
great framework mind you, but there's nothing special about it that influenced
the choices in design for the more recent versions of JS.

~~~
Kiro
Not even querySelector?

~~~
VeejayRampay
I think querySelector and querySelectorAll are simply more generic versions of
the traditional approach of using getElementById and getElementsByTagName, but
it's possible that the greater versatility of $ influenced the later design of
querySelector, indeed. Then again, it was not a jab at jQuery, which proved to
be a fantastic tool for a decade in the field of web development.

------
the_duke
Has Hack actually gotten meaningful adoption outside of Facebook?

I never hear about anyone using it...

~~~
muglug
Slack does, and some (all?) of MediaWiki. Outside of that, I don't think it's
enjoyed the sort of penetration of other OS projects from FB

~~~
smsm42
MediaWiki doesn't use Hack. Wikimedia Foundation servers (which run Wikipedias
and other sites) do use HHVM, but the code is 100% PHP-compatible and still
runs fine on standard PHP.

~~~
appleflaxen
this is a really helpful distinction that isn't made on the other comments
that address HHVM and MW; thank you!

------
krapp
Well, this is disappointing. I really like Hack and I was hoping it would take
off, but judging from this thread it seems unlikely the language is going
anywhere worth following. I guess it's lucky that I only have one project
written in it...that I now have to convert back to PHP.

I'm really going to miss XHP. Native XML support has ruined me for templating
frameworks. I never want to write HTML as concatenated strings ever again.

~~~
fredemmott
For completeness: Sara Golemon started porting Facebook's old PHP5
implementation of XHP to PHP7 - you can find it here:
[https://github.com/phplang/xhp](https://github.com/phplang/xhp) \+
[https://github.com/phplang/xhp-lib](https://github.com/phplang/xhp-lib)

------
tiffanyh
This is pure syntax sugar but will Hack now clean up the PHP inconsistency
with function naming and return values?

E.g. FunctionName() vs function_name().

Or

E.g. return 5x20; vs return "5"x10;

~~~
fredemmott
Function naming:

We're moving towards functions_like_this(),
instanceAndStaticMethodsLikeThis(), and async functions like foo_async() and
methods like fooAsync(). We're unlikely to change the PHP builtins, but we're
fairly likely to build replacements - for example, Hack Arrays are best used
with [https://github.com/hhvm/hsl](https://github.com/hhvm/hsl) instead of the
PHP array functions, and this also provides replacements for common string
operations that are consistent and fit well with the Hack type system (e.g.
nullable or throw an exception instead of falseable).

For return values, I'm not sure exactly what you mean - could you give a full
example? If I take your example verbatim, it's a syntax error in both Hack and
PHP - if I go for "5"*10, it's a Hack error
([https://gist.github.com/fredemmott/90c5f8eca17d1d4e1204f0085...](https://gist.github.com/fredemmott/90c5f8eca17d1d4e1204f0085cc120f5))

~~~
tiffanyh
From the blog post:

    
    
      HHVM will not aim to target PHP7
    

If you don't plan to support PHP5 anymore and HHVM is not targeted at PHP7 ...
then my ask is to just make a better language and drop ALL of PHP baggage.

When you say:

    
    
      We're unlikely to change the PHP builtins
    

That concerns me. Because why even break support from PHP7 if you don't plan
to change (fix) the builtins?

~~~
mxawng
As fredemmott said above, we're hoping to build replacements for the various
PHP builtins that we want to be a core part of Hack. I think that replacing
the functionality provided by PHP builtins will be a less confusing transition
experience than retrofitting them with modified behaviors would.

Once we do have a compelling and comprehensive Hack Standard Library, I
wouldn't be surprised if we dropped PHP builtins in favor of that.

------
thatonechad
I tried out Hacklang a bit and I really enjoyed it. However I could not get
xdebug or any type of debugging to work with it. Also the lack of an editor on
the calibre of PHPStorm (atom is not great at all) made me give up. I am just
hoping for PHP7 to move in the right direction.

------
crescentfresh
First I'm hearing of Hack! Didn't realize HHVM had under it's wing _two_
languages.

------
ecesena
What are the best framework for web dev on top of hack/hhvm? Last time I used
PHP I was using yii (yes-it-is). Wondering what framework can someone use
today if she has to start from scratch on hack.

~~~
fredemmott
[https://github.com/hhvm/hack-router/](https://github.com/hhvm/hack-router/)
and [https://github.com/hhvm/hack-router-
codegen/](https://github.com/hhvm/hack-router-codegen/) power docs.hhvm.com
and some of our other users; they do have problems such as extremely lacking
documentation, which I'm going to be addressing soon.

This is definitely an area we're planning on working on - and this post is
meant to be announcing the start of this work, not that it's ready :)

------
royge
If HHVM(Hack) will drop all the inconsistencies and weirdness of PHP in their
implementation the better since it's no longer be compatible with PHP anyway.

~~~
rurban
That's the plan. Break the old nonsense, like the one they mentioned: refs and
refcount. Everybody should switch to Hack, it's a much better and safer
language.

------
fiatjaf
[removed language flame war]

~~~
grzm
There are plenty of places where you can view arguments for and against PHP
alone and in comparison to Python and Ruby on the internet. This submission is
specifically about HHVM. Asking people to justify the use of PHP in such a
context is just inviting a language flame war. Please don't.

------
ohdrat
Guess I'll mosey on back to OCaml then...

------
merb
I wonder why they just don't deprecate HHVM altogether and maybe create a HACK
version on top of GraalVM. This would probably be way more performant and
probably might be better for integration into other systems.

------
memracom
I think that these changes mean the death knell for PHP in any version, for
small companies. There is still a place for Hack or PHP7 in very large
operations, but startups, and businesses that run at smaller scale, really
should walk away from PHP entirely as soon as possible.

Two reasonable directions to choose are Python Three with a framework like
Flask (lighweight) or Django (heavy duty). Or go to the JVM with something
like Grails framework (heavy duty) on the Groovy language. Ratpack is a
lightweight framework for Groovy and there is also an interesting option to
use Vaadin 8 which lets you put your GUI code into the main app rather than
writing separate Javascript code.

When making your decision, be sure to consider the huge JVM ecosystem that
integrates quite easily with Groovy including development tools like Jenkins
and SOAPUI that can be scripted with Groovy. And the Python side also has a
fairly extensive ecosystem of libraries as well.

The skill level of Python and Java/Groovy developers tends to be higher than
PHP which has always attracted people who would learn just enought to get by.

The software dev community has gone through an explosion of diversity in the
past 2 decades and that has enabled a lot of experimentation with new ways of
doing this. There is a lot of good in this. But now we are in a period of
contraction. Some of this is manifested in the spread of functional
capabilities via libraries such as reactive extensions and functional features
being added to languages like Java and Javascript. Another manifestation is
the fading of PERL from prominence, and this is now happening to PHP as well
as Ruby.

This is evolution. Embrace it or face your personal extinction as a software
developer.

~~~
muglug
> This is evolution. Embrace it or face your personal extinction as a software
> developer.

Woah there Mr Hyperbole.

The reason PHP is still in use, and not dead or dying, is that it's one of the
simplest languages to write server-side code in.

That means it's remarkably easy to hack something together quickly, with no
compilation step to get in the way.

Unless that changes in a drastic fashion, projects will continue to get
started in PHP, and PHP's user base will continue to grow, and (hopefully) the
language will continue to improve to accommodate that growth.

