Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102427
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.173 as permitted sender)
MIME-Version: 1.0
References: <DM5PR0201MB354280334D34629059189156AC4A0@DM5PR0201MB3542.namprd02.prod.outlook.com>
 <CAESVnVpcd7xBB+A+6Kz0b5JqnPaZfQitWLtXi-4_cZA8kf2knw@mail.gmail.com>
In-Reply-To: <CAESVnVpcd7xBB+A+6Kz0b5JqnPaZfQitWLtXi-4_cZA8kf2knw@mail.gmail.com>
Date: Mon, 25 Jun 2018 17:58:10 +0300
Message-ID: <CAJHtznzVSPLLvGJW471GoKbBE7uB5oLYJ+8Lq-=vYSP-LHeYww@mail.gmail.com>
To: pollita@php.net
Cc: Zeev Suraski <zeev@zend.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000dd662d056f789c80"
Subject: Re: [PHP-DEV] PHP 2^3
From: vsuraski@gmail.com (Zeev Suraski)

--000000000000dd662d056f789c80
Content-Type: text/plain; charset="UTF-8"

Thanks for taking the time to respond!

On Mon, Jun 25, 2018 at 5:27 PM Sara Golemon <pollita@php.net> wrote:

> 1/ Pushing 8.0 as 7.3 + 1 means we're going to rush deprecations into
> 7.3 which is already in fire-hose mode of last-minute, under-planned
> "hey I want this toy" requests.  Yes, deprecations are a little bit
> more sweaty ice cube in terms of late deprecations being lower risk
> that late additions, but it's still turning into a rushed thing during
> a season when some folks are off on holiday break.  The FF is in
> Summer in part *because* this is a bad time to introduce RFCs.
>

Note that I did propose that we actually have a thin depredations-only PHP
7.4 (to give credit where credit's due, that's Dmitry's idea).  This gives
us ample time without having to rush deprecations into 7.3

2/ In several of theses cases we're talking about something that's not
> even fully scoped out yet.  Async, for example, "requires a lot more
> research".  Yes, that research can probably be completed and turned
> into an implementation in the 1.5 years we have till the Nov 2019 GA
> (whatever version that ends up being), but there are multiple items on
> this list which are not (seemingly) fully fleshed out.
>

I think it's entirely unreaslitic (or remarkably optimistic if you prefer)
to think we'd have this done in under 18 months.  There's still tons of
work we'd want to do in the JIT front, the work is entirely ahead of us as
far as async and preloading are concerned - and that's without even
factoring in the amount of time that discussions would take nor the fact
we're likely to still be busy with 7.3 for quite some time.  Releasing it
at the end of 2019 effectively means we can squeeze such a huge version in
the same timeline we took for incredibly smaller versions like 7.1, 7.2 or
7.3.  I think we're good, but we're not THAT good :)  I also don't think
there's anything 'sacred' about releasing at the end of a particular year.


> 3/ When I read phrases like "open the door for new types of workloads
> for PHP (non Web)", and "one of the key reasons Node is gaining
> popularity", and " 'bleeding edge' technologies, such as AI and
> Machine Learning" I smell a trend of chasing the new hotness and
> worrying about factors other than making PHP the best language for the
> Web.  Growing PHP is great, and evolving it into new areas is also
> potentially quite good, but we *have* history showing what happens
> when we come up with something new to chase after that then turns out
> to be underwhelming, undermaintained, and underutilized.  I've also
> seen what a JIT does in terms of additional complexity, it's not
> pretty.
>

First, I'll admit that there's definitely some of that happening.  But to
paraphrase my daughters - "I didn't start it!".  In other words - people
are very actively looking for ways to run PHP in a Node-like manner, and
with the shift towards micro-services - I don't think it's a fad.  I think
we need to go there if we are to stay relevant.

With JIT - it's bit of a mixed bag.  After so many efforts went into it and
we managed to get something pretty nice going - it was also a bit of a
solution looking for a problem.  That's where the idea of expanding PHP to
other areas came from.  And to be perfectly honest - it's not that I
invented this approach either - people have been using PHP for non-Web
workloads since forever.  Plus, we're still hopeful that it would show
benefits for the Web world, especially in conjunction with preloading and
the fact it'll enable PHP-based built-in functions (which is another thing
we've wanted for a long time).

With FFI, I think the risks are low and the potential benefits are
substantial.  Out of the major ideas, this is probably the one I'm mentally
least attached to - but here too, I see few downsides to doing it.

4/ When the $(%* did we body swap, because it's not quite full
> turnabout, but I'm suddenly having flashbacks of "give the language a
> rest". :)


People evolve :)


>
> Please don't construe this response as entirely negative.  As I said
> in other replies, I'm actually quite excited about these new things
> and the directions they open up, and it may be that you and Dimitri
> have been spending quite a lot of time thinking about them and their
> implications to the language going forward.  However, like the NG
> branch prior to 7.0, most of this appears to lack any sort of plan for
> those of us not in your private email threads.  Yes, we've discussed
> all of them at one point or another, but apart from the JIT, there's
> been no obvious signs of work on any of them, which brings me back to
> being concerned about 7.3 suddenly being flagged as the last 7.x
> release within mere DAYS of its planned feature freeze branch date
> without warning.
>

I'm not taking your comments negatively at all!  I do want to point out
that this time around everything we did was done in public as much as we
could - including both JIT and FFI.  There hasn't been any meaningful
progress beyond some conference-style brainstorming regarding preloading
and async, virtually all of the work is ahead of us here.  If this sounds
like it's messy, it's because it kind of is - because it's a lot more of a
plan-for-a-plan than it is an actual plan.  Again, the main goal here is to
gauge the level of willingness of people to say that PHP 8 is going to be
the next feature release of PHP after 7.3, and to allocate a longer
timeline for us to successfully deliver it than the standard yearly cadence
(as was pretty much always the case with major versions).  We will of
course discuss each and every one of the ideas separately.  Of course, in
theory it's possible we'd shoot down all of the different ideas - but I'm
at least hopeful that wouldn't be the case and we'd have enough material
(both from these ideas and perhaps others) to release a major version
within 2-2.5 years.

Possible alternative.  Still aim for Nov 2019 GA of 8.0, but have a
> 7.4 in parallel with it.  This (sort of) happened with 4.4 being
> released between 5.0 and 5.1 (I know, not quite the same).  This would
> give us a couple advantages:
>
> 1/ Take our time with these last-minute "deprecate all the things"
> RFCs that have suddenly popped up.
> 2/ Have an escape hatch to delay 8.0 till Nov 2020 if implementations
> for the big stuff aren't quite ready for whatever reason rather than
> being forced to push them to 9.0


I still think that Dmitry's idea that we have a deprecation-only 7.4
sometime in 2019 makes sense.  If we really wanted to we could make it a
deprecation+some extras version, but I'm concerned about fragmenting our
scarce resources.  I don't think the sky will fall in case we take 18-24
months between our last 7.x feature release and 8.0.  We've had that
between 5.6 and 7.0 and I think it worked pretty well.

Thanks for the feedback!

Zeev

--000000000000dd662d056f789c80--