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 <maxsem.wiki(a)gmail.com> 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
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l