
Ending PHP Support, and the Future of Hack - dcgudeman
https://hhvm.com/blog/2018/09/12/end-of-php-support-future-of-hack.html
======
luord
Another day, another weird dogmatic "static vs dynamic" discussion, with
inaccurate comments like "the dynamic hype is dying", or "static is making a
comeback" or "static is not really relevant anymore".

Are people really that unfamiliar with the history of computer science?
There's no hype, there's no comeback; both static and dynamic languages have
existed for over six decades. Both styles have been around as long as computer
science has been a thing and will continue to exist as long as programming is
a thing.

~~~
realharo
_> both static and dynamic languages have existed for over six decades_

For a long time however, if you wanted a mainstream (well supported, large
ecosystem) language with static typing, you pretty much had to deal with
languages like Java or C++, with their pretty limited type systems and other
unrelated design choices that may not appeal to you. It was either that, or
going full dynamic. Or some niche language with poor library support.

These days there are plenty of popular languages where you can get all the
benefits of static typing with far fewer compromises (Kotlin, Swift, Rust,
Scala, TypeScript, etc.) AND a more expressive type system. So the field has
definitely changed.

~~~
norswap
The type system of Kotlin is pretty much the same as that of Java (the only
addition is that of declaration-site variance, which essentially allows you to
elide some of these annoying wildcards at the use-site).

I'm not familiar enough with the others, but I have A LOT of doubts. Only
Scala's type system is clearly more powerful/expressive than Java.

Also, through templating, C++ type system is made quite expressive.

~~~
realharo
Compared to Java, Kotlin also adds nullable types and sealed classes. The
built-in syntax for lambda types could also be considered a part of the type
system. Or the fact that inline lambdas let you use non-local returns
([https://kotlinlang.org/docs/reference/inline-
functions.html#...](https://kotlinlang.org/docs/reference/inline-
functions.html#non-local-returns)) where the explicit `inline` can be
considered a part of the type.

As for the others, check out for example TypeScript's mapped types
([https://www.typescriptlang.org/docs/handbook/advanced-
types....](https://www.typescriptlang.org/docs/handbook/advanced-
types.html#mapped-types)), or Swift's extensions
([https://docs.swift.org/swift-
book/LanguageGuide/Extensions.h...](https://docs.swift.org/swift-
book/LanguageGuide/Extensions.html)).

Considering that Java or C++ don't even have sum types, it's not exactly a
high bar to cross.

~~~
norswap
Fair point for nullables, although that is already possible through annotation
processing (see the checkers framework) - but there is a good faith argument
that this isn't "core" enough.

The _syntax_ for functions and inlining are not part of the type system.
Inlining especially, is a useful language feature, and has to be checked at
compile-type, but is unrelated with types.

Sum types, really you can have that with just inheritance (base class with
package private constructor + final sub-classes). What Java lacks is a nice
way to pattern-match/switch over types (which Kotlin does nicely with flow
typing), but again that isn't really the type system (although it does make
the type system nicer to use, certainly).

~~~
realharo
_> Fair point for nullables, although that is already possible through
annotation processing (see the checkers framework) - but there is a good faith
argument that this isn't "core" enough._

It also wasn't available in a practically usable form until relatively
recently (when talking about history), so my very first point about the
timeline of languages still stands. Plus it adds even more verbosity to an
already very verbose language.

 _> The syntax for functions_

I meant function types, e.g. the variable `val a = {}` has a type `() ->
Unit`, which is a real type in Kotlin.

Of course you can achieve a similar thing in Java with SAM interfaces
(including all the weirdly named ones in `java.util.function`), so I'd call
that the same level of expressiveness.

I don't see why `inline` wouldn't be a part of the type system, when you can
have a function argument (that is itself a function) that either

\- can be passed into anything that expects a function as an argument - as
long as the rest of the type matches of course (a non-inline argument)

\- can only be invoked or passed into another inline function (an inline
argument)

Conceptually, this has some parallels to C++'s const-correctness ("any
matching pointer can go here" vs. "only a non-const pointer can go here",
"this function cannot be called via this pointer" etc.), which is generally
considered a part of its type system.

It's just a matter of definition really.

 _> Sum types, really you can have that with just inheritance (base class with
package private constructor + final sub-classes)._

The person that uses those classes (I'll call them consumer), e.g. writes a
function that takes the base class as an argument, then has to be aware of the
internal implementation - the compiler won't help you there. If someone else
who maintains that part of code adds a new subclass, you'll have an
unaccounted for possibility and there is no way to safeguard against that
(unless you redesign the whole part of the codebase using crutches like the
visitor pattern).

There is no good way to express "this value can be one of these types, but no
other" in Java's type system from the consumer's point of view (only from the
producer's). I may not be using the correct terms here but hopefully you get
what I mean. As far as the Java compiler knows, you are not _really_
expressing a sum type, and that comes with the mentioned negative
consequences.

------
muglug
I don't think there are enough backend web developers in the world to support
vibrant communities for both PHP and Hack.

Unless Facebook's prepared to invest a lot in community-building, Hack and
similar FB projects will go the way of VBScript and Silverlight.

~~~
erikb
The thing is that the enterprises seem to be okay with them being the only
user of their open source projects. Don't ask me why they then decide to do
open source projects in the first place, but that's what I'm seeing.

~~~
PunchTornado
A lot of other big players used Hack (Etsy, Wikipedia and others). Don't know
if they switched back to PHP7 though.

~~~
beberlei
Afaik Etsy and Wikipedia only used HHVM for the performance win and not the
Hack language on top. Since Wikipedias tech stack "MediaWIki" is heavily used
by PHP companies it can't be using Hack features.

Slack came out with a blog post a few month ago, writing that they use the
Hack features on top of HHVM. That is the only one besides Facebook that I
know of (there are probably more)

Edit: Source for Etsy using PHP 7 now
[https://speakerdeck.com/wcgallego/hitting-the-turbo-
button-u...](https://speakerdeck.com/wcgallego/hitting-the-turbo-button-
upgrading-to-php-7-at-etsy-1)

------
wprapido
With PHP7, HHVM became largely irrelevant. It had played a great role and
contributed to the PHP's maturing immensely though!

~~~
endymi0n
This is really interesting, I've seen this pattern somewhere. IMHO,
CoffeeScript had a really similar effect on the development of JavaScript /
EcmaScript, but then, it quickly started going extinct. Same with IO.js vs.
Node.JS, which was eventually re-integrated into the main line.

It's interesting how apparently sometimes you just need to step aside to break
old conventions and demonstrate new capabilities, but eventually, you'll need
the support of the community to pull it through: Plus, it's always a gamble.
Python barely made it over to v3 after 10 years. I'm not sure if Perl will
ever cross the gap or if Perl 6 fragmented the community for good.

Just some random thoughts though on the dynamics of open source, I'm glad for
the experience of PHP at the beginning of my career, but I wouldn't touch it
or any derivatives any time again having free choice. Too much Heinz™ design:
Grown, not made.

~~~
aruggirello
Speaking of fragmentation, we still have 3/4 of users on PHP 5.x, and support
for v5.6 (the last 5.x release) is coming to an end soon!

~~~
acomjean
And honestly the jump from php 5.6 -> 7 is pretty painless. Its probably the
lack of tests for a lot of old 5.6 software that gives people fear of
upgrading. php development has gotten a lot better.

I think support for 7.0 is ending soon too.

~~~
charrondev
Yes. It reaches the end of its support at the end of this year, and PHP 7.1
next year.

------
Nitramp
It's interesting to see this, and curious if you look at it from an
organizational decision making standpoint. Hypothetically, because I'm not
involved in any of this, but still:

Facebook was initially implemented using PHP, and you can read this process as
continued iteration based on this very early decision. From the outside,
Facebook seems to have always taken what they had, taken the problems they
currently had, and made the most incremental change they could to fix whatever
problem they had. From PHP to HHVM to Hack to dropping PHP support, they
continued iterating on what code base and development chain they currently
had.

If you take a step back though, Facebook is gradually moving to a different
programming environment, from a dynamic language with very loose semantics to
a statically typed system with (from code I've seen in e.g. phabricator) a
very different programming style than run of the mill PHP. While iterating
incrementally, they still ended up forking PHP and moving to a different
language.

The approach is quite different from e.g. Twitter though, who started off
using Ruby on Rails, and then moved everything to an entirely different tool
chain (Scala) when they found Rails couldn't hold up with their problem set.

This difference in approaches isn't quite the same as the good old "rewrite vs
refactor" dichotomy. Twitter's change was certainly incremental too, moving
individual services to Scala bit by bit, setting them live incrementally
instead of a "big bang" rewrite where everything moves to Scala one day.

I think the main difference is planning horizon: do you opportunistically fix
whatever is broken right now, or do you make a long term plan on what you want
your future platform to be, and then set out to get there?

Opportunistic fixing has the advantage that you can be pretty certain you're
fixing the right problem, and don't invest in YAGNI features. On the other
hand, you risk ending up in local optima. Pouring a lot of effort into PHP
makes sense if you plan to continue using it - but if you end up forking the
language anyway, you loose a lot of the advantages of a shared ecosystem (and
arguably damage the existing ecosystem in the process through fragmentation).

You could equally well imagine Facebook picking a different future tech stack
five years ago, be it Rust or Go or whatever, and add the features they miss
from PHP to it. I think it's an interesting thought experiment where that'd
have taken them. I have no idea if taking that path would have been better for
any of {Facebook, PHP, target language X, world}.

~~~
pron
> On the other hand, you risk ending up in local optima.

This would only be a risk if the difference between the local optimum and the
global optimum is large, but there is no evidence to suggest that is the case
(and a lack of evidence for a big effect is usually evidence against it). To
be more precise, no one has been able to find a drastic productivity boost
among apparently reasonable alternatives, so either there's a plateau or no
one has found the global optimum. Either way, as things stand, there is no
such risk.

A risk that does exist is failing to create a viable development environment
or simply not having the resources to even attempt it. As others noted, this
is a big risk (or an almost guaranteed failure) for small organizations, but
hardly one for a very big one.

~~~
humanrebar
On the contrary, certain kinds of technical debt are only paid off in full,
not in increments. Supporting entire languages, for instance: experts,
toolchains, dev environments, packaging systems, core libraries, telemetry
libraries, etc.

The large difference between a local maximum and a goal is clear. The question
is whether the cost to get there is acceptable.

------
dsign
Duly noted the desire of Hack to have more "typing". It seems that as soon as
projects growth beyond a certain size, everybody starts wanting to add that.

I wonder what would be the optimal lifecycle for long projects. Obviously,
"start with dynamic language X until you reach 10^n lines of code, then fork X
and add types to it" doesn't work for smaller companies :-(

~~~
Tehnix
I feel like dynamically types programming languages had a huge hype period,
and then all the startups we saw write in their dynamic languages later ended
up adding types, because maintainability is simply SO much easier when you
have a good type system and the compiler can help you. I say that coming from
a road starting at PHP, then moving to Python, JavaScript, Java, Haskell.

Funnily enough, strongly statically typed languages are not bad at all for the
early prototyping stage. In fact, I would argue that they are much better, but
you have to switch your approach from slapping some functions out, to instead
slapping out some ADTs, that form the basis of your app.

A lot of good advice for Haskell is given in this thread
[https://www.reddit.com/r/haskell/comments/7sr8k7/fast_protot...](https://www.reddit.com/r/haskell/comments/7sr8k7/fast_prototyping_how_to_experiences/).

One important thing to note though, is that I honestly don’t think this will
work well, unless the language has at least type inference and support for
ADTs, newtypes (or, tagged types) and pattern matching at the minimum. Less
than that, and you end up fighting the type system, instead of letting it be
your help and guide.

~~~
tarsinge
> and then all the startups we saw write in their dynamic languages later
> ended up adding types, because maintainability

Maybe because they weren't startups anymore?

Honestly I don't understand the deal with type errors in simple web apps :
every input is a string which is parsed into the correct type. After this,
with good naming and conventions operations should be obvious, e.g. why would
you try to do a mathematical operation between a customer's name and it's
account balance?

To me it looks like these days the hype is copying whatever big names are
doing regarding maintainability without having nearly the same constraints
(static typing, huge frameworks, ...).

~~~
maaaats
> _why would you try to do a mathematical operation between a customer 's name
> and it's account balance_

that's a straw man to js typing, and never a problem in practice. What's more
often happening, is that you change the structure of some object in your store
somewhere, that's passed around a lot. And you forget to update the usage one
of those places and stuff break runtime.

~~~
vidarh
My experience in going from being very insistent on static typing and moving
to Ruby (after lots of hesitation) is that you run into lots of type errors,
chances are you _also_ have uncaught logic errors in code your test suite
isn't exercising. E.g. the above example would presumable be caught if you
actually tested all the code acting on the account balance, even without a
single test to explicitly test the types.

That goes irrespective of if those type errors are caught at compile time or
runtime - if those errors aren't caught by your test suite, odds are you have
a problem that static typing will not fix but writing more tests will. In
either case my response to type errors these days is to consider it a bug in
the test coverage.

(I'm sure some will argue that typing in languages like Haskell avoids this
more than others, and that might be true, but languages like Haskell are too
hard to work with for most people to ever get mainstream traction; I'd love to
see more experimentation in making more advanced type systems more accessible,
though)

~~~
wsy
It is true that all type errors can also be caught by additional tests. But is
this the most efficient strategy? I would think that letting the compiler find
certain classes of errors should be cheaper than writing and maintaining tests
for these error classes.

~~~
vidarh
My point was that you rarely need to write test _to catch type errors_. You
write tests to determine if a unit of code works as expected. In doing so you
tend to exercise the conditions that cause type errors as a side effect.

Let's say foo() internally calls bar(). If I pass a given valid input to foo()
it passes the wrong type to bar(). If I pass another valid input to foo() it
passes the wrong value but of the right type to bar().

If you ensure full test coverage of foo() you will catch both. Type checking
in your compiler will only cover the first case, so you still need the same
test coverage anyway to have confidence in the code.

~~~
glennpratt
Full test coverage of foo() is hard to prove. Have you exercised every
argument possibility, every exception that could be thrown and every
global/class/instance var reference? Working with Ruby most of my career, my
experience is probably not.

A good type system is much more thourough and let's your tests focus on
behavior.

~~~
vidarh
That's what you have coverage checkers for.

And you don't need full coverage. Aiming for full coverage is a folly - you
aim to cover the API surfaces you're actually using. If you still get lots of
runtime errors something is very wrong with how you test your code.

> A good type system is much more thourough and let's your tests focus on
> behavior.

The problem is no languages I'd be willing to use have a good type system that
actually covers much.

~~~
glennpratt
> The problem is no languages I'd be willing to use have a good type system
> that actually covers much.

This is basically down to opinion, and I can't argue with it. I've
collaborated on Ruby projects for about 10 years, I love the language, but my
experience says a large code base, with test coverage, regularly breaks on
things that most type systems wouldn't allow.

Dependencies often cause subtle breaks like this, even in big, common ones.

On top of that, this requires paranoia to avoid breaking callers. With a good
type system, you can largely discard that paranoia.

------
tscherno
Poor Wikipedia will need to migrate back to php7 runtime which still could be
complex despite of language compatibility.

~~~
beberlei
Wikipedia was always a PHP software and just running on HHVM for the
performance gain, not for the Hack language. The underlying MediaWiki software
is used outside of Wikipedia a lot, always on the PHP not HHVM stack. I expect
its only a project for their operations team and should be managable.

~~~
piotrkubisa
Could you tell more about MediaWiki use-cases outside Wikipedia? I know there
is a lot of open-source projects which has MediaWiki installed for
documentation (i.e. Arch Linux). Are there any usage in "internal
documentation" software (like alternative to Confluence)? Why they have chosen
the MediaWiki not other software which can be easily self-hosted / deployed on
a premise?

~~~
codewiz
MediaWiki is indeed very easy to self-host. I've been running several
instances for the FSF and Sugar Labs.

From the sysadmin perspective, it's a dream app to deploy: just unpack (or git
clone) the latest release in a directory, point Apache (or Nginx) at it, and
continue in the guided setup process (which involves creating a database,
typically MySQL).

Updates are also painless: there's a php maintenance script which updates the
schema. I've kept MW instances for ~10 years without running into any
problems.

Things get a little more interesting if your add a ton of extensions, or badly
maintained ones.

I wish I could say the same of Django and Rails apps! <trollface>

------
crispytx
Diverging from PHP was a good move as PHP 7 has largely caught up with HHVM in
terms of speed. That's really neat that Facebook invented their own language
to meet their needs. Will have to mess around with it further sometime.

~~~
jaytaylor
Agreed, Hack appears to be a move to fork into a PHP-esque language that FB
engineering feels will be better for their software lifecycle goals and needs:

\- Handle numeric boundary cases in a more intuitive way.

\- Is Typed.

\- Replace reference parameters in favor of a new keyword, "inout".

\- Change package management and testing framework to be less annoying and
more streamlined. This will be yarn (from npm, as in the one written in
Javascript), and their own custom flavor of testing framework, hh-test, to
replace PHPUnit.

I wonder how many existing open-source PHP projects will remain compatible
with HHVM? The post seems to indicate compatibility will not be a priority and
that it's a fully breaking change. If this is true, it seems the "empty
cocktail room" effect will be a major challenge and problem.

    
    
        Jane:
        "Hey, you can do this project in PHP or Hack."
    
        Alice:
        "Okay, I'll go with PHP because there's
        already a shitton of good libraries that might
        be useful to me or that I already know."
    

I.e. Why would you use a language with few open source libraries over a very
similar language with exponentially more?

When I want types, I can already use Go, Java, or even Typescript, just to
name a few terrific options. These days it seems like a no-brainer to me.

The effort seems like a lot of trouble to go to just to shave off some
annoyances / "rogue hairs".

Curious if there's an angle I'm missing.

One argument for making it an open-source language / project and trying to
eventually grow it could be so FB can more easily hire folks who are already
know the Hack language.

    
    
        Marke:
        "I'll do it in Hack because my only dream is
        to work at Facebook!"
    

May not be that many Marke's out there.

~~~
eganist
> Why would you use a language with few open source libraries over a very
> similar language with exponentially more?

Fewer unvetted libraries from a security and code quality angle.

Not saying it's good from a general engineering angle, but in an environment
like Facebook which can afford to over-engineer, the third party dependency
risk mitigation is a good side effect.

But my argument here is a pretty polarizing one as it implies security-
through-obscurity. I promise I'm not; I'm just pragmatic about how many
abandoned or poorly maintained open source libraries end up being relied-upon
regardless of how that challenge is solved-for in CI/CD.

~~~
jaytaylor
I see what you're saying, and question the assumption that a higher percentage
of Hack libraries will be high quality.

You raise a valid concern, and also this issue cuts both ways.

The FB libs have a good chance of being well-maintained. This will be true for
PHP and Hack, alike.

The rate of library neglect will be approximately equal between the two
languages.

The real question is: What does the data say about project / library neglect?
I'd guess neglect rates may correspond inversely with language popularity.

Languages with fewer people writing code in them will have more opportunity
for abandonment and neglect.

Who wrote and is relying on the library seems like a better candidate for
predictor of proper future maintenance compared to language flavor.

~~~
eganist
> Languages with fewer people writing code in them will have more opportunity
> for abandonment and neglect.

This would be true in the public space.

I don't know if it holds when the language is internal to the company and
people are incentivized effectively to keep them up to date.

------
alexandercrohde
Hmm, I don't really get it. But I suppose I don't really know if I bought the
value proposition of HHVM in the first place.

~~~
smsm42
hhvm had some performance advantages over PHP 5. They are largely gone with
PHP 7 AFAIK.

~~~
alexandercrohde
Right, this is part of what I don't get.

PHP is open source. Instead of building a way to compile PHP and then a VM,
and making all the adjustments necessary for Hack, why didn't FB just spend
that energy submitting a patch to make PHP faster?

Now I also don't know if I buy that MAX_INT + 1 and pass-by-reference is a
pressing enough use case to break compatibility. I'd be open to hearing why,
but I'd be starting from a position of skepticism.

~~~
jasone
The people who initially developed HPHP (the PHP-to-C++ transpiler) were not
the same people who initially developed HHVM (the VM/JIT). I was one of the
people who started the HHVM project, and we recognized early on that we must
base our work on HPHP to have any hope of eventually replacing HPHP on
Facebook's production systems. Indeed, had we chosen otherwise, our project
would certainly have failed. It took us three years to initially ship HHVM,
and HPHP's ancillary ecosystem dramatically diverged from PHP during that
time. Furthermore, the people who initially developed Hack were yet another
team, and they based their work on HHVM for much the same reason as HHVM was
based on HPHP.

In an ideal world of perfect cooperation, perhaps all these projects would
have been enhancements to PHP, but a chain of independent rational decisions
produced very different results.

~~~
wpietri
Has anybody written up the history? I'd be fascinated to read a blog post
series on all that.

------
m_st
Article from Marco Arment about exactly this, from 2014.

[https://marco.org/2014/03/21/hack](https://marco.org/2014/03/21/hack)

------
kevinconaway
From the outside looking in, the most interesting part of the post is the note
about their new release cadence:

> As we expect the language to evolve rapidly, we strongly recommend using the
> regular releases instead of the LTS releases for large projects; while this
> does mean you need to upgrade more often, both us and our users have found
> that it is generally easier to catch up on 2 months worth of changes 3 times
> as often than 6 months of changes in one go. We will also be re-evaluating
> the length of our release cycle; one possibility is that we will move to
> releases every 4 weeks, with these releases being supported for 6-8 weeks.

That cycle will work for FB where they are constantly iterating and also have
early insight as to where the language is going before they get there but for
anyone on the outside or for slower moving projects, that cadence seems fairly
punishing.

Is that a big change from how they release now?

------
jrs95
This is bad news for Slack, I would think. I believe they went all in on HHVM
+ Hack, which is going to be increasingly incompatible with 3rd party packages
now.

~~~
yurishimo
Is it possible they could find inefficiencies in their codebase to make up the
performance difference with regular PHP? Or maybe they'll just need to add
more servers to make up the difference?

~~~
aylmao
Adding more servers stops being a good option after a certain point. If you're
a small company running on 20 servers you can increase your performance by 5%
if you add just one more. Install it in one day, boom.

If you're running on 200,000 servers, a 5% increase is 10,000 servers. That
means opening a new building in your data-center, making sure your recruiting
team has resources to hire enough staff for it, then hiring that staff,
negotiating contracts with the power company, the component suppliers,
building permits, hopefully you have enough network capacity otherwise you'll
have to expand that too, etc.

It's many months of work and a lot more expensive than hiring a handful of
engineers to tackle performance and maybe build some libraries in-house.

------
pritambarhate
Do you think dynamic types was a mistake? Almost all popular dynamically typed
languages have some sort of type hinting. All new promising languages have
chosen to be statically typed.

~~~
wasd884
Dynamic types weren't a mistake, but they were overused IMO. It's technically
scripting, not programming, but can you imagine if Bash files were type
hinted? For small scripts, solo projects or quick fixes, dynamic typing is
great because it's fast! On the flip side, large codebases should (on the
whole) not use dynamic types because of all the safety they fail to provide!
As you said, most dynamically typed languages are moving towards some sort of
type hinting and that's because high quality developers demand it when working
on medium to large projects.

~~~
strzibny
> It's technically scripting, not programming

Nope. Dynamic types have nothing to do with scripting vs programming. What a
nonsense!

Sorry I had to:).

~~~
wasd884
You misunderstood me. I agree that scripting and programming have nothing to
do with dynamic types.

> It's technically scripting, not programming, but can you imagine if Bash
> files were type hinted?

I was clarifying that writing Bash files was scripting and not programming.

~~~
ttsda
How is writing bash files not programming though?

I understand it's historically been called 'scripting' instead, but
'technically' it's as much of a programming language as Python is, don't you
think?

~~~
dx87
"Technically" of course it's just as much of a programming language, but
"practically" it's normally used to kick off other programs, and is just glue
meant to pass input and output between programs. FWIW, when people use Python
for small automation tasks, I usually hear them referred to as scripts instead
of programs. Program seems to imply that it's useful on its own, script
implies that it doesn't serve a purpose besides running other programs that
are generally useful.

------
TACIXAT
I tried using hack once, spent a few days on it. It was a total disaster from
a user-developer perspective. The documentation was poor and certain modules
(the xhtml or equivalent module in particular) would not work due to versions
or dependencies. If they are going to make a push they need to really make it
easier to get up and running on.

------
codr4
Static/dynamic is obviously a gradient. I find it a bit sad that it always
seems to be either or these days, either no types or a full blown static
generic type system.

I'm all for the ability to type variables and functions, as long as I'm still
allowed to be exactly as precise as I feel like.

Many would call that static typing, since there are types in the code that the
compiler consumes. But my own attempts [0] at building such languages tell me
that the result is still more dynamic than most.

[0] [https://github.com/codr4life/snabl](https://github.com/codr4life/snabl)

------
kijin
I wonder how this will affect major websites outside of Facebook that rely on
HHVM, such as Wikipedia. They made a big announcement when they switched to
HHVM in early 2015. Have they moved over to PHP 7 yet?

~~~
lathiat
They are planning to move to PHP7 largely because of this change but also
since PHP7 closed the performance gap:
[https://phabricator.wikimedia.org/T176370](https://phabricator.wikimedia.org/T176370)

------
sigi45
Aaand Hack ist dead. At least for everyone outside fb.

Not sure why fb even made it public. First baiting everyone by switching and
now having full control.

Not sure who would risk that dependency.

~~~
detaro
Do you mean HHVM or Hack?

~~~
sigi45
Both

------
sebastianavina
Sincere question, but PHP is still widely used?

I remember that around the year 2002 it was almost the only choice (besides
Perl) on shared hosting, but on this days its just a nasty language and with
so many beautiful languages like Python GoLang and Ruby why would anyone use
PHP for a new development?

~~~
dieulot
Yes, and it keeps growing:
[https://w3techs.com/technologies/history_overview/programmin...](https://w3techs.com/technologies/history_overview/programming_language/ms/y)

------
giancarlostoro
So who is using HHVM other than Facebook? Genuinly curious? Will be
interesting to see where Hack goes altogether.

------
debacle
I think this is a step in the right direction. PHP's refusal to break BC in
the stdlib, among other things is probably the biggest impediment to the
language being more widely accepted.

By breaking compatibility with PHP, Hack is going to be able to adapt more
quickly and create a stronger language. Hopefully, Facebook will have the
wherewithal to promote Hack to PHP (and other) developers, and grow the
ecosystem as it can.

~~~
burnte
> PHP's refusal to break BC in the stdlib, among other things is probably the
> biggest impediment to the language being more widely accepted.

PHP is one of the most widely used languages on the web. Their backward
compatibility is absolutely part of that reason, too. Refusal to break
compatibility may be holding it back in some technical areas, but it's
certainly not hurting the language in popularity and use.

~~~
debacle
There's no reason not to break BC in 7.4. The people still running 5.3 aren't
going to not upgrade to 7.4 because you fixed the array functions.

~~~
ars
That is a completely false sentence. People develop PHP sites, launch them and
expect them to work, even if the server is upgraded to the latest PHP.

Breaking their code on a PHP upgrade is a great way to strand them on old
unsupported versions of PHP. Not everyone has resources to change things that
used to work because of some "array function" change that doesn't really make
any difference.

------
ape4
I would have liked "Hack" to be some play on "PHP". Maybe "HPH". PHP++ or
PHPPP

------
oh-kumudo
Which makes sense. Facebook now is big enough to sustain a programming
language on its own. And for Hack, I would assume it mainly to replace where
the PHP used to be, which is a shallow API composition layer, no heavy lifting
stuff. To fulfill that purpose alone, one need not to have super diverse
ecosystem providing all kinds of libraries, just focus on a limited core
functionality should suffice.

------
erikb
Wasn't HHVM created as compiler or interpreter for PHP?

~~~
anticensor
Yes but they added so much features that the core became hard to maintain.

------
k__
Does this mean Facebook pulls its resources out of PHP?

Weren't they THE big player that kept PHP alive in the last years?

~~~
SwellJoe
PHP is still more widely deployed for small/medium websites than any other
language. WordPress still powers more websites than any other single
application, for example.

Facebook was always an anomaly in supporting/using PHP at that scale. PHP was
never a major player in very large companies...until facebook. I think this is
a return to the mean, rather than a seismic shift in a new direction.

That's not to say PHP isn't fading...it is. But, I don't think this is a huge
hit to PHP.

~~~
k__
I see.

Last time I used it was 8 years ago and I had the impression it would have
been gone by now if it wasn't for Facebook pouring money in it.

~~~
ars
Your impression is completely different from the reality.

Facebook was/is irrelevant to PHP adoption. Their only effect was to increase
the speed of PHP.

PHP is widely used because it's really great language for web development.
It's better than the other choices because of ease and rapidity of
development, and because it was _designed for_ the web, not as a regular
language with web things bolted on (Python and JAVA are examples of that).

It is not fading at all. Some developers think it's too easy of a language, so
they discount it as for beginners only. That's about it. It's a kind of
snobbery, which I'm glad to see seems to be vanishing with the release of
PHP7.

~~~
SwellJoe
"Some developers think it's too easy of a language"

Good lord, who thinks that? PHP is a terrifyingly complex and difficult
language. I'm not saying it's bad, it's been very successful for its intended
purpose. But, it is definitely _not_ an easy language.

It's got thousands of standard functions in the global name space (admittedly,
it has been recognized that this was a mistake, but it's all still in there),
quite a lot of syntax, and some weird syntax that's unlike any other language,
a high level of verbosity in many places (due, in part, to that whole
thousands of functions in the global namespace thing, but also due to an
apparent admiration for Java during a critical period in PHP development), a
variety of quirks and inconsistencies, etc. PHP is a very big, very complex,
language, that takes years to master. I can't see how it can be called "easy".
Many other languages are much better teaching/learning languages. PHP is
popular and widely discussed, which helps with learning it. PHP is also very
easy to deploy, because it is the "standard" web language...you just upload
your files to the right directory on most hosting platforms and you're done.
That's great, but doesn't really make the language easy.

~~~
ars
> It's got thousands of standard functions in the global name space

There is exactly 0 difference between prefixing a function, and putting it in
a different namespace. All those functions have prefixes and are very easy to
locate and understand.

It's literally the difference between \foo\bar and foo_bar. It makes no
difference for understanding the function.

The only advantage of a formal namespace is you can "own" it, and other code
can't put things in there. Not having it does not making the core language
harder to understand.

> quite a lot of syntax

It's basically the syntax of C. The most complicated parts are lambda
functions and references. And that's nothing. Where are you getting "quite a
lot of syntax" from?

Classes have a bit of syntax, but it's hardly "quite a lot", and the nice this
is you don't have to learn any of it to get started.

> a high level of verbosity in many places

Where? PHP is not especially verbose. Examples?

> a variety of quirks and inconsistencies, etc.

There's basically just two: Comparing an empty string and the mistake with
precedence on the ternary operator. Everything else confusing is the
difference between arrays and Key/Value structures, and it's not really not
that hard to figure out.

> PHP is a very big, very complex, language, that takes years to master.

It is not very big. The core language can be learned in a week. It's not very
complex either - it's among the easiest languages out there.

> Many other languages are much better teaching/learning languages.

Not because they are easier - because they are _harder_!! They are more
structured and you have to understand more - that makes them good to teach
concepts. PHP was never intended as a teaching language.

~~~
SwellJoe
"Not because they are easier - because they are harder!!"

That doesn't make sense.

I think we'll just have to agree to disagree. I believe there are many
languages, including some often used for web development, that are easier (and
better teaching/learning languages) than PHP in several regards. Python is the
most obvious but Ruby also fits the bill.

------
aasasd
Welp, so much for “PHP has JIT too.”

~~~
ehnto
They increased performance of the language enough that it caught up to HHVM.
PHP7 is wildly faster than previous PHP versions. In other words, HHVMs value
proposition of speed is no longer as relevant.

PHP is still working on a JIT implementation but I honestly don't think it's
that important for now.

~~~
postalrat
In my experience HHVM is still quite a bit faster once it gets going.

