[rabino]

I'm confused about what the goal of this is. The best thing about PHP is its dynamic nature, and the fact that any new page load is a completely new universe. Why would you want to loose that and compile it to a, well, compiled language?

[dsp1234]

The subheading for their blog post summarizes it nicely:

"In our last blog post we discussed some of the advantages and shortcomings of PHP and the .NET framework, and pointed out why the two should not be compared with each other. Today, we are introducing a tool that can bridge the gap between these two frameworks, enable the developer to produce code in PHP that is both-way interoperable with .NET, and therefore make use of the specific advantages of both, PHP and the .NET framework:"

[recursive]

A language's dynamic typing is a separate question from whether it's compiled. PHP can remain dynamically typed, and still be compiled.

[pchp]

This.

[Sanddancer]

There are already compiled versions of PHP, like HHVM. Compiling a program does not preclude it from being dynamic. Also, I'd argue that throwing out everything with each page load is throwing out the baby with the bathwater. It's possible to create new workers for each task which don't share any sort of state. So you can both precompile and destroy the world with each instance.

[dsp1234]

So you can both precompile and destroy the world with each instance.

I'm pretty sure that's what PHP 5 does already with the opcache.

Looking at non-jit engines, I'm more familiar with jscript/vbscript under active server pages than I am with PHP. But even that engine from 1998 caches the "compiled" bytecode of the page in a scripting engine that can be run on any thread, and can be cloned. Once the engine is finished running the current request, it drops the state from the request and awaits a new request with new state. It never destroys the scripting engine unless an actual file changes. I'm pretty sure that PHP 5.5 is similar in that regard (though I'm certainly not 100%).

So when talking about 'throwing out everything' with each page load, I'm pretty sure that most people are talking about the actual state from the request, not bytecode cache. Compare this with something like nodejs where it's possible to reference a global variable from inside a request handler, and thus have a possibly hidden global dependency. Whereas with ASP/PHP, it's just not possible without making concerted efforts to call out to non-script land.

Specifically, for a non-jitted language, a very reasonable concession to performance is to go ahead and force each request to run in it's own world, and then 'destroy the world', because at that point you can do huge amounts of clean up since you can make a guarantee that no other request could possibly use that request's state.

[bluedino]

PHP is simpler to learn/use, for simpler things.

.NET performs better, and not being able to change the code can be considered a feature in some cases.

So you get the best of both worlds.

[cpayne]

VERY opinionated! You are going to get downvoted to heck for comments like that.

Try personalizing it: 'I found PHP much easier to learn for ..... but when I wanted xyz performance, .NET performance was abc.'

Give a use case / example where no code changes helped.

As others have said, apparently PHP7 is better than PHP5...

You are (VERY!) unlikely to change the minds of die hard .NET or PHP people, but you'll have a lot more potential with someone who doesn't know either...