Chad: thanks for writing up all of those in one place. I'm not actually
trying to argue *for* Hack here. My argument is just that we should take
the time to lay out the arguments carefully on both sides, since this is a
decision that is likely to have long-lasting effects. Think of this like
the traditional [[devil's advocate]] process for canonizing a saint. I'm
just challenging us to take a hard look at our reasoning and make sure it
is well-founded technically.
In my ideal world we'd take your excellent point-by-point argument and try
to rigorously quantify each, just to satisfy ourselves that we've done due
diligence. You say "there's not much migration cost moving to PHP7" --
well, it would be nice to assign someone to go through the details in a
little more detail to double-check that. "Various benchmarks dhow HHVM and
PHP7 performance to be roughly on par" -- firmer numbers would be nice, as
you say. I think Tim was already going to do this? "A bunch of major
projects have already dropped HHVM" -- again, can we take the devil's
advocate position and ask the HHVM team who *hasn't* dropped HHVM ;) and
ask for their reasons? You also raise some points about packaging and
portability that I could probably counter by pointing out that HHVM has an
ARM and PowerPC JIT now (
http://hhvm.com/blog/2017/03/09/how-the-cyber-elephant-got-his-arm.html),
while Zend's JIT-in-progress only supports x86. We could also poke at the
HHVM folks and ask about their packaging plans, since they (according to
their announcement) are going to "reinvest in open source". You also
mentioned PHP's long history of FLOSS without also mentioning their long
history at sucking at security. And we could try to quantify how dependent
PHP is on Zend contributions vs how dependent HHVM is on facebook
contributions. We can get numbers on this, we don't have to assume things.
The HHVM announcement specifically mentioned that they will maintain
compatibility with composer and phpunit, so that seems to be a wash.
The references/destructors thing is actually really interesting as a
technical discussion. The reason given for removing these is all about
performance, in particular the performance hit you get from ref-counting as
opposed to pure GC. There's been a lot of really good GC work done in the
past two decades; see
https://news.ycombinator.com/item?id=11759762
although I like to cite
https://www.cs.princeton.edu/~appel/papers/45.ps as
foundational. It may be a good opportunity to take a hard look at our
Hooks system and figure out if its design is future-proof.
--scott
On Tue, Sep 19, 2017 at 2:04 PM, Chad <innocentkiller(a)gmail.com> wrote:
On Tue, Sep 19, 2017 at 10:50 AM C. Scott Ananian
<cananian(a)wikimedia.org>
wrote:
Chad: the more you argue that it's not even
worth considering, the more
I'm
going to push back and ask for actual numbers and
facts. ;)
As I said in my prior message: it's been considered, and discarded rather
quickly. It doesn't need much further introspection than that. A couple of
major points:
* Brian W's point is correct: there's not much migration cost at all moving
to PHP7. Moving between PHP versions has always been pretty easy for us in
MW--we write very conservative code as it is.
* Various (there's lots from lots of people) benchmarks routinely show HHVM
and PHP7--especially 7.1+--performance to be roughly on par, depending on
workloads. We can get some firmer numbers here.
** A bunch of major projects have already dropped HHVM for PHP7+. Etsy,
Symphony, Wordpress (they no longer test against it)
* Swapping to HHVM/Hack would abandon many/most of our downstream users --
the stats Stas pointed to way far back shows world install base as well
under 0.5% of all PHP runtimes.
* Speaking of downstream users: HHVM has always been a second-class citizen
on non-Linux OSes. It's always been wonky on OSX (I would know, I was the
first person to ever get it built), and I don't think anyone's ever got it
working on Windows outside of Cygwin--please correct me if I'm wrong?
* It greatly complicates setup and development work for both WMF and
volunteers.
** Did I mention almost nobody has up to date packages for this?
* PHP has a long-documented history of working as a proper FLOSS project.
Facebook's track record here has been less than stellar--it comes in fits
and starts and there's a lot of "throwing code over the wall"
** We have a core PHP contributor (Stas) on this list. Other than
occasional patches we've shipped upstream to HHVM, I doubt anyone would
claim themselves a core HHVM contributor around here [maybe Tim early on,
heh]
* Choices HHVM is going to make upstream (references, destuctors) are a
/huge/ issue for us. The former is basically a requirement for our Hooks
system and the latter is used all over the dang place for profiling and
other fun scope-based tricks.
* Libraries we use -- composer, phpunit, etc can not be depended on to
support Hack in the long term, and there's no tooling in the HHVM world for
this (promises notwithstanding).
-Chad
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
(
http://cscott.net)