PHP 8 to Add a JIT

This is the RFC with more technical details <a href="https:&#x2F;&#x2F;wiki.php.net&#x2F;rfc&#x2F;jit" rel="nofollow">https:&#x2F;&#x2F;wiki.php.net&#x2F;rfc&#x2F;jit</a>.<p>I believe their plan is to emit low-level code directly via DynAsm, without their own intermediate representation.<p>This kind of approach has been tried again and again and again and every project doing this either not got the results they wanted and given up or has had to go back and add a proper intermediate representation.<p>Examples include Rust adding MIR before emitting LLVM, Rubinius trying to emit LLVM directly from Ruby and not getting good results so giving up, JRuby adding an IR before emitting Java byte code, Dropbox&#x27;s Pyston implementation of Python that emitted LLVM directly where they gave up entirely, etc, etc, etc.<p>Low level backends are not going to do the kind of key optimisations such as scalar replacement of aggregates that are table stakes for making a dynamic language perform well - they just don&#x27;t have the high-level semantic model of the language needed to do it.<p>Maybe they&#x27;ve got some new ideas, or maybe simplicity is a key constraint for them, but I predict from experience that they will need an intermediate representation to get the results that they want.

There is something to be said about PHP&#x27;s staying power. The early versions of the language weren&#x27;t considered &quot;right&quot;. Except maybe they were <i>right</i> for the problem at hand.<p>The way I see it was PHP captured the <i>vector of change</i>, and left ample room for future developments. Both internal changes (hello, bytecode; hello, JIT), language level features (hi there, namespaces), and runtime level features (oh hai, countless built in classes and functions).<p>Moreover, unlike many framework that shone brightly and burned out quickly (Rails?), PHP captured the essence of the environment: HTTP is stateless, and URLs aren&#x27;t uniformly routable from either end, and well-formed HTML&#x2F;XML&#x2F;JSON is just a subset of tag soup.<p><i>Worse is better.</i>

PHP is doing great! I like the direction it is going in. PHP 7.4 also introduced nice features to improve static typing. The FFI is pretty cool too. You also get free performance improvements while remaining mostly backward compatible. It is trying very hard to stay relevant and I believe it is succeeding.

I am pretty impressed with the path PHP has been taking lately. They have moved the language from being a mess into aggressively incorporating modern features at a very rapid pace. Especially PHP7 is a really nice language.

My feelings about PHP are stuck in what I remember from 2004. If I’m starting a new backend web project in 2019, should I be considering PHP over Ruby, Python, or TypeScript? Why or why not? I’m curious to hear from anyone who’s used it professionally in the last couple years.

One very important motivation what I do not see clearly delineated in this post is for Event-driven applications. Swoole[1] is an example of a PHP framework which enable some very interesting uses such as Websocket services.<p>In those long lived processes, a JIT really shines!<p>[1] <a href="https:&#x2F;&#x2F;www.swoole.co.uk&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.swoole.co.uk&#x2F;</a>

Article appears to be from the same person that maintains apcu, a very popular user space kv memory cache for PHP. <a href="https:&#x2F;&#x2F;github.com&#x2F;krakjoe&#x2F;apcu" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;krakjoe&#x2F;apcu</a>

I&#x27;m happy PHP is still there, because other much better languages missed a lot of good things that PHP got right immediately (in the context of web development):<p>1. You may add complexity if you want but the <i>bare metal</i> of web is that you have some printf() like output construct plus a trivial &lt;? ?&gt; interpolation thing. Then who wants more can add more, but this should be what you get immediately for free, without template languages.<p>2. Languages, even high level ones, should be reasonably fast.<p>3. Setting up an environment should be trivial.<p>4. By default things are created and die in the context of a page load. Then if you want to optimize things, you may have <i>additional constructs</i> to create persistent connections, objects, whatever. But give me this huge garbage collector that is a stateless execution, by default.<p>5. A set of libraries already included so that for most things I don&#x27;t have to go and find some solution.<p>Many other competitors failed so big in that regards that I really wanted PHP to get better as a language (like it is doing) so that it was not a so bad experience like at the start, because I was pretty sure the others would hardly fix the above points.

PHP has made huge strides with 7.0+ but honestly a JIT was nowhere on my list of feature requests. We use it at work (with CodeIgniter) and it gives the company a big pool of reasonably qualified talent. For anything outside our web apps, we switch to Python. I find it unlikely that new PHP shops are going to use it to do all the CPU-bound things we aren&#x27;t using it for now.<p>But who knows? I wouldn&#x27;t have thought it would be as popular as it is now, if you&#x27;d asked me 5 years ago.

Love what they&#x27;ve been doing on PHP lately :)<p>&gt; However, this in fact opens the door on things such as machine learning, 3d rendering, 2d (gui) rendering, and data analysis, to name just a few.<p>Shouldn&#x27;t we get decent threading built in before we consider most of those? I&#x27;ve hit that wall many times when processing larger amounts of data w&#x2F; php scripts. I know about the pthreads plugin but nothing beats a first class citizen like goroutines for go or similar.

Apart from ubiquitous cheap hosting another big factor in PHP&#x27;s early success was the numerous magazines pumping out &quot;Build X with PHP and MySQL&quot; articles. The shelves of newsagents were full of them in the early 2000s, some devoted purely to PHP development. Dreamweaver also adopted PHP for its dynamic site generator which made it accessible to front-end developers.

Need some love here for AOLServer and TCL. Got &quot;Philip &amp; Alex&#x27;s Guide to Web Publishing&quot; and within two weeks had a major Mutual Fund company up on the web. The CICS interface was a little wonky, but it worked and worked well.<p>I do things now with Wordpress, since that grew and was maintained past AOL server. I always look forward to improvements in PHP, the last few releases have made huge strides in page load times

I care enough to click the link. But I don&#x27;t care enough to know anything about PHP 8. Why is the author insulting me with the intro?

So if JIT involves compiling into native machine code, can we expect that in the future JIT capability would help PHP devs implement compiling whole PHP project into native (like a single .exe binary for Windows)?

Doesn&#x27;t this duplicate the effort of HHVM?

For a second I read that as &quot;PDP 8...&quot;

The article says that this will help PHP in areas outside of the web. But what others areas actually <i>want</i> PHP? Even in its niche, the web, it has fallen out of grace for new projects.

I already submitted that: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19531611" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19531611</a>