About third-parties. * Regardless of whether PHP 7 (or 8, or 9) is more similar to PHP 5 than Hack is. * Regardless of whether upgrading from PHP 5 to 7 is more or less difficult than upgrading to Hack. * Regardless of whether Zend PHP is going to make big backwards-incompatible changes in the future (like HHVM is doing now in Hack, e.g. what if Zend PHP 8 or 9 were to also drop references and destructors?).
Regardless of these "our" costs, a site-admin must work with the options available. We can expect current PHP 5 deployments to also (soon) have PHP 7. Shared hosting, dedicated hosting (with shell but limited packages), and platform-as-a-service (PaaS), and other environments have, or will soon, provide an option/package/image for PHP 7. But having them consider a new run-time (e.g. Node, Go, Perl, Hack) was always a good argument against "Let's rewrite MediaWiki in X". On the other hand, I don't think we should consider it as something that can't happen. We shouldn't decide on the account of every single hosting provider. Some are probably still running PHP 4 and customers will have decided to switch to a more caring provider. If no providers add Hack, the loss is ours (leaving site-admins with no similar-cost options). If enough providers switch, the loss is the provider's (customer leaves or provider follows suit). I don't think a PHP-only provider is necessarily cheaper than a more diverse provider. They're just differently focussed. The marketshare of sites runnable on pure "LAMP" seems to be shrinking with the other run-times gaining popularity, and new run-times being introduced. I'd expect a hosting service providing only Zend PHP to have a shrinking customer base in the long run. We might not be looking at "Will they add Hack as the first non-PHP run-time option", but rather "Will they add Hack among the other run-times". How do we feel about that? Does this seem like something that could happen, as well as something we could *help* make happen? -- Timo On Mon, Sep 18, 2017 at 9:58 PM, Max Semenik <[email protected]> wrote: > Today, the HHVM developers made an announcement[1] that they have plans of > ceasing to maintain 100% PHP7 compatibility and concentrating on Hack > instead. > > While this does not mean that we need to take an action immediately, > eventually we will have to decide something. As I see it, our options are: > > 1) Continue requiring that MediaWiki uses a common set of HHVM and Zend > PHP. This, however, is a dead end and will make things progressively harder > as the implementations will diverge and various Composer libraries we use > will start requiring some Zend-specific features. > > 2) Declare our loyalty to HHVM. This will result in most of our current > users being unable to upgrade, eventually producing what amounts to a > WMF-only product and lots of installations with outdated MediaWiki having > security holes. At least we will be able to convert to Hack eventually. > This is a very clean-cut case of vendor lock-in though, and if Facebook > decides to switch their code base to something shinier, we'll be deep in > trouble. > > 3) Revert WMF to Zend and forget about HHVM. This will result in > performance degradation, however it will not be that dramatic: when we > upgraded, we switched to HHVM from PHP 5.3 which was really outdated, while > 5.6 and 7 provided nice performance improvements. > > I personally think that 3) is the only viable option in the long run. What > do you think? > > ---- > [1] http://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html > > -- > Best regards, > Max Semenik ([[User:MaxSem]]) > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
