Hi! PHP 7 is faster than 5.6, and probably be on almost any workload, from my experience (the degree of speedup would vary of course). As for comparison with hhvm, I heard various reports, but I think spending some time on seriously testing it (I mean creating proper production setup, and directing either captured/replayed or real traffic to it) is the best way to go. -- Stas Malyshev smalyshev(a)wikimedia.org

Other tools we are using, such as Phabricator, will also be following HHVM to Hack (presumably). Facebook, as the largest (by engineering budget) production user of PHP, will certainly have an outsized influence on the direction of the platform and surrounding ecosystem. If we follow path #3 we're probably also committing to supporting Zend development long-term as the primary production user. --scott On Mon, Sep 18, 2017 at 5:26 PM, Brian Wolff <bawolff(a)gmail.com> wrote: -- (http://cscott.net)

Hi! I am not sure this is the case. Mozilla recently declared they want to use Phabricator[1], but I heard no mention about HHVM. Which makes me think that one stays on PHP. Also, Phabricator is now independent from Facebook, afaik, since it's developers have separate company, Phacility. [1] https://wiki.mozilla.org/Phabricator -- Stas Malyshev smalyshev(a)wikimedia.org

Hi! Wow. I can see why they're doing it (those are sources of most complications ans security issues in the language, references being especially weird and tricky). But dropping those would certainly mean very heavy incompatibility with PHP, by which point it'd be completely separate language. Which probably excludes Max's #2 from consideration altogether. Should it be on the TechCom agenda and should we have some public discussion on IRC in RFC format for this soon? -- Stas Malyshev smalyshev(a)wikimedia.org

On Mon, Sep 18, 2017 at 9:51 PM, Chad <innocentkiller(a)gmail.com> wrote: Technically, I did outline the arguments for (2), earlier on this thread. It was a bit allegorical, though: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2018/Writing_Tips… This should be seriously considered, not just dismissed. I agree the short timeline seems to push us toward reverting to Zend. But it is worth having a meaningful discussion about the long-term outlook. Which VM is likely to be better supported in 15 years' time? Which VM would we rather adopt and maintain indefinitely ourselves, if needed -- since in a 15 yr timeframe it's entirely possible that (a) Facebook could abandon Hack/HHVM, or (b) the PHP Zend team could implode. Maintaining control over our core runtime is important; I think we should at least discuss long-term contingencies if either goes down. Obviously, our future was most stable when we (briefly!) had a choice between two strong runtimes... but that opportunity seems to be vanishing. Practically speaking, it's not really a choice between "lock-in" and "no lock in" -- we have to choose to align our futures with either Zend Technologies Ltd or Facebook. One of these is *much* better funded than the other. It is likely that the project with the most funding will continue to have the better performance. There are other big users of HHVM -- do we know what other members of the larger community are doing? We've heard that Phabricator intends to follow PHP 7. Etsy also shifted to HHVM, do we know what their plans are? --scott -- (http://cscott.net)

Hi! Depends on which ones you're talking about. Syntax ones may or may not find its way into PHP, but performance ones would probably be completely different from HHVM - i.e. the resulting performance may or may not be on par or better, but reusing most of the performance work on HHVM in PHP would not be possible due to completely different engine internals. So pretty much all that can be taken from HHVM into PHP would be "this syntax looks like a good idea, let's reimplement it". -- Stas Malyshev smalyshev(a)wikimedia.org

On Tue, Sep 19, 2017 at 11:33 AM, bawolff <bawolff+wn(a)gmail.com> wrote: That's why I argued we should consider the code quality of both, and determine which we'd feel most comfortable supporting on our own in the case our crystal balls are wrong and we end up holding the bag for the runtime. (This is just one factor to consider; my argument is that we should carefully enumerate the various factors before making an evaluation, not just dismiss any of the options out of hand.) --scott -- (http://cscott.net)

On Tue, Sep 19, 2017 at 9:21 AM, C. Scott Ananian <cananian(a)wikimedia.org> wrote: Etsy 'experimented' with HHVM [0] and then eventually switched to PHP7 as their primary runtime. The blog posts about this are a little scattered, but Rasmus spoke about it [1] and Etsy started the phan project [2]. For what it's worth, my opinion is that PHP is an actual FLOSS software project with years of history and core contributions from Zend who make their living with PHP. HHVM is a well funded internal project from Facebook that has experimented with FLOSS but ultimately is controlled by the internal needs of Facebook. For me the choice here is obviously to back the community driven FLOSS project and help them continue to thrive. [0]: https://codeascraft.com/2015/04/06/experimenting-with-hhvm-at-etsy/ [1]: https://codeascraft.com/speakers/rasmus-lerdorf-deploying-php-7/ [2]: https://github.com/phan/phan Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Manager, Cloud Services Boise, ID USA irc: bd808 v:415.839.6885 x6855

On Tue, Sep 19, 2017 at 9:40 AM C. Scott Ananian <cananian(a)wikimedia.org> wrote: I'm not trying to simplify this into community vs. facebook. And let's also be clear: we never chose HHVM for Hack. We don't use Hack. The one experiment I had at trying Hack never panned out. MediaWiki is in PHP, not Hack. The *only* reason we're having a language discussion is because HHVM has announced that they're abandoning PHP in favor of Hack. If someone had some to the list last week and said "Hey let's abandon PHP for XYZLang" they would've been rightly laughed off. The debate here is between runtimes for PHP, and on the long enough timescale there's only one option. PHP has a long-standing history of being a viable runtime. HHVM does not. I don't see this as an A/B choice at all, but rather a clear path forward. So sure: let's have an RfC/TechComm meeting to work out the details, but let's not pretend that option #2 is even remotely viable. It is not. -Chad

On Tue, Sep 19, 2017 at 10:28 AM C. Scott Ananian <cananian(a)wikimedia.org> wrote: I see everyone saying #1 for now and #2 down the road. You're the only one here who seems to think #3 is even worth considering. The rest of us have--rightly--dismissed it already. -Chad

Hi, On 09/19/2017 10:27 AM, C. Scott Ananian wrote: Well, kind of. MediaWiki has full support for PHP 7 while still maintaining PHP 5 support. I don't think anyone has argued for anything besides #2. There's already an open RfC[1] about bumping the minimum PHP requirement to 7.x. [1] https://phabricator.wikimedia.org/T172165 -- Legoktm

Hi! I think this is a very good point. There are other ways to support PHP too. Like assisting in regular testing of upcoming versions. Helping writing the docs. Contributing to RFC discussions (we have a large codebase, heavily visited site, and a lot of experience dealing with it, surely there could be a thing or two we could contribute). Triaging the bugs (one of the most necessary, thankless, and under-appreciated jobs in an open-source project). Probably more... -- Stas Malyshev smalyshev(a)wikimedia.org

Hi! By your mention of Jani, I derive it was a long time ago :) Quite a lot changed since then, even though the internals list is still not the most friendly place on the nets. But the processes got better, I think, and the level of maturity of both discussion and participants increased. Also, thank you for the kind words, and I'll be glad to help with what I can if we need something done in PHP core. -- Stas Malyshev smalyshev(a)wikimedia.org

Hi! 15 years is a lot to predict. 15 years ago Facebook, Twitter, Reddit and Linkedin did not exist and Slashdot, Livejournal, etc. were all the rage. We don't even know if Facebook as such would exist in 15 years or would have budget to support its own language. While (b) could happen, PHP project is not very dependent on Zend for its existence. Zend owns none of the infrastructure or processes, and while a lot of performance work on PHP 7 was conducted by Zend team (and they are still working on improvements AFAIK), there are plenty of community members that do not work for Zend and do not depend on Zend in any way. Of course, it is possible that the whole community would implode, but here we have many more stakeholders than in Hack case, where the stakeholder is mostly a single - albeit large and currently very successful - company. Again, I do not think this is the right statement to make. The control of Zend Tech as a company over the future of PHP is much less than Facebook's one over Hack (which is pretty much absolute). PHP is guided by the community, decisions are taken by using community processes in which Zend does not have any special role, and PHP project could survive reasonably survive without Zend, even if with less resources. Most PHP infrastructure - Composer, debugging, IDEs, profiling, code quality, frameworks, etc. - are completely independent of Zend (which also has a number of tools, but it is not the only provider). So I do not think it is an adequate comparison. I am not sure if Hack has an open-source community outside Facebook (if anybody has pointers to that, please share - commit numbers certainly don't tell much) - but it is pretty clear to me that Facebook is in absolute control over this platform. This is not the case with Zend and PHP. -- Stas Malyshev smalyshev(a)wikimedia.org

Hi, On 09/18/2017 05:13 PM, Tim Starling wrote: On Reddit[1], a member of the HHVM team clarified they plan on dropping support for destructors *from Hack* soon. (Not that I think it really makes any difference in what our long-term plan should be.) [1] https://www.reddit.com/r/PHP/comments/70wtky/the_future_of_hhvm/dn6skdn/ -- Legoktm

On Tue, Sep 19, 2017 at 10:13:47AM +1000, Tim Starling wrote: The next step would be the upgrade of the mw* fleet to Debian stretch while still using HHVM 3.18 (to minimise disruption since we've stabilised 3.18 in it's current build). That work is tracked at T174431. 3.18 will be supported by upstream for at least another six months (and if the migration drags further I can roll custom 3.18 security backports from later LTS releases) Debian stretch ships PHP7, so that'd be a good stepstone to migrate back to Zend. Cheers, Moritz

Sounds like a good idea. +Daniel for scheduling. Best, Victoria

On 19/09/17 20:56, Gilles Dubuc wrote: We had an IRC meeting about this yesterday. Here is the log: <https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-09-27-21.03.log.html> We mostly talked about the migration plan for production, including the likely timeline. -- Tim Starling

On Wed, Sep 20, 2017 at 10:56 PM, Brion Vibber &lt;bvibber(a)wikimedia.org&gt; wrote: I think this is the more viable option too, mostly not to cause huge issues to non-Wikimedia users. The ease of installation and operation of PHP on most platforms compared to HHVM is incomparable. Just to make an example, I don't remember having to check the code of the VM to understand what an ini setting does with PHP (or even PHP-fpm), while with HHVM that has been a recurring pain, as options come and go without any warning between versions, not to mention the online docs that can even be plainly misleading. At the moment, there is no doubt PHP is a much friendlier environment for any third-party wiki. But I think there is other value in going the PHP7 way; I had actually pitched the idea of switching to PHP7 for some time now, for various reasons, namely: - We use HHVM differently than what Facebook does. For instance, we use the fcgi server mode, and not the pure http one, and we don't run in repoAuth mode. This has brought us new bugs to solve every time we upgrade, as there is no battle testing in production for those code patterns at scale before we use it. - The recent, prolonged difficulty of interaction with the FLOSS community, although acknowledged by the HHVM team as something they're willing to fix, is worrying in itself. - PHP7 has shown performance comparable to HHVM for most PHP shops that migrated. So the single most compelling reason for which we migrated (performance) might not be a factor anymore. Using a runtime readily available (and security-patched) by the upstream distribution would make the ops team lives easier as well. As for the actual migration: I don't think there is any need to panic or rush to a decision, but the timeline is pretty set: by the end of 2018, when official support for HHVM 3.24 will end, any migration should be well underway within the WMF infrastructure. I expect a migration from HHVM to PHP 7 to be a less formidable undertaking than the switch from PHP 5.3 to HHVM - we did repay a good deal t of the tech debt in the Wikimedia Foundation installation back then, and we won't have to change radically the way we serve MediaWiki, as PHP 7 works as a FastCGI server as well. Still, it will take time and resources, and it needs to be planned in advance. One important consequence of the announcement for Wikimedia is that we won't be able to use any version of MediaWiki not compatible with PHP 5.x until we transition to PHP7 (unless we decide to support both HHVM and PHP7). This might be important in steering the timing of the change in MediaWiki itself. Cheers, Giuseppe -- Giuseppe Lavagetto, Ph.d. Senior Technical Operations Engineer, Wikimedia Foundation