PHP 8 to Add a JIT | Hacker News Reader

PHP 8 to Add a JIT

blog.krakjoe.ninja

317 pointsUkiahSmith183 comments

This is the RFC with more technical details https://wiki.php.net/rfc/jit.

I believe their plan is to emit low-level code directly via DynAsm, without their own intermediate representation.

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.

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's Pyston implementation of Python that emitted LLVM directly where they gave up entirely, etc, etc, etc.

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't have the high-level semantic model of the language needed to do it.

Maybe they'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.

Chris - any recommendations on a good simple IR to study?

MIR is probably a good example as it solves the problem I'm suggesting they'll encounter https://blog.rust-lang.org/2016/04/19/MIR.html.

Ideal is also a classic https://www.oracle.com/technetwork/java/javase/tech/c2-ir95-....

Thanks!

Not sure if this qualifies as intermediate representation in the LLVM sense, but PHP has opcodes already, it is not fully interpreted anymore (like it was in PHP 3).

These opcodes are used for optimizations and cached for the lifetime of the PHP process (across multiple requests).

That's probably too low-level. Usually an AST is needed that is void of all syntactic sugar, yet can express the required data flows and dependencies so the trivial substitutions/replacements/caching and refactorings can be done at this level.

Lower level bytecode lacks these higher level references (it usually has a lot of indices that index into raw lookup tables, but no real symbols that refer to results of computations and other variables).

There does appear to be an internal AST in php7: https://github.com/nikic/php-ast

PHP has had an AST for years now.

Of course, but the opcode is lower level than that. And that was what the parent comment mentioned.

LuaJIT and WebKit both produce their IR from the bytecode, IIUC.

Not sure why you think this is the case: there are numerous JITs/VMs that optimize starting from bytecode e.g. all JVMs, WebAssembly, V8, JSC,...

Can you point me to some paper/reference about this? AFAIK it doesn't matter whether you have an AST or bytecode. Optimizations are done on an IR anyways.

Usually an AST is needed that is void of all syntactic sugar,

That’s how I’ve always see “AST” used, but not the following:

yet can express the required data flows and dependencies so the trivial substitutions/replacements/caching and refactorings can be done at this level.

Is what you describe some flavor of ‘augmented’ AST? Does that have a name other than AST?

> making a dynamic language perform well

Perhaps the advantage here is that PHP really all that dynamic. PHP is much closer in design to taking Java and compiling it on every request than it is like Python or Ruby.

Well, you can do

    $moo = "hello";
    $zork = "moo";
    echo $$zork; // hello

It doesn't get much more dynamic than that.

That looks it merely needs some reflection support (variable name lookup).

Isn't reflection slow as hell?

If not please correct me.

It's less fast than direct lookups, but if the compiler supports it properly, it shouldn't be any slower than a associative array lookup.

  echo $FOO[$BAR];
  echo $$BAZ;
  >>>
  
  push FOO.ptr
  push BAR.ptr
  call hash_get
  push ax
  call print
  
  push local_table // static per compiled scope
  push BAZ.ptr
  call hash_get
  push [ax+24] // entry->value
  call print

You'd probably want to add error handling (to both cases) and accessing a global variable that didn't exist when the code was compiled will likely be slow, but if becomes a preformance bottleneck you can always rewrite it to something easier to compile.

And of course a smart JIT compiler can even put the variable access lookup in an inline cache on the function so that in the future it's a direct type + key = offset calculation rather than a memory lookup and the hash_get call is avoided.

True. I was aiming for the simplest example that could pass as real general-case-ish assembly; there's plenty of room for improvement.

The whole point of a JIT is that you don't do naive variable name lookup.

With a proper intermediate representation you'd connect that $$ variable lookup directly to the original variable's edge.

It can. Python, for example, builds up classes at runtime. PHP builds up classes at compile time. There are plenty of other examples. PHP is really dynamic through eval() but that's more rare.

Although PHP does support the above syntax, it's actually pretty rare in production code. PHP can be optimized like JavaScript is: perform direct variable/member access but provide a slow path for these kinds of dynamic lookups.

You can't just wave away the impact of having eval though. Just the fact that it exists means you need to keep around some supporting state like variable names. You can't do full constant folding and eliminate all intermediate steps for example if there a chance a runtime-created code will reach into your frame and want them back.

Similar things are done by JS engines and others nowadays. They optimize and keep the original stuff in case assumptions stop holding.

eval() is scoped to the current block. If you even just ignored JITing any function with eval() in it then you'd still get quite far.

I used to use that pattern $$ frequently for library code.

I wish PHP had classes spread across several files like ASP.NET.

The PHP way for that is Traits

I think he means partial classes in C#. Great for code generators.

You can do this in PHP:

    <?php
    eval('class Hello {public static function you(){echo "Yes!";}}');
    Hello::you();

or this:

    <?php
    file_put_contents('c.php', '<?php class Hello {public static function you(){echo "Yes!";}}');
    require('c.php');
    Hello::you();

Thus generating a class at runtime-ish.

It's also very much frowned upon so a slow path is fine.

The _get and _set magic methods (called when getting/setting missing properties) are quite common especially for frameworks.

(Rust had an AST and HIR before MIR happened, incidentally.)

I respect that the PHP maintainers recognize that it is not enough to accept a working JIT implementation - they have to understand and maintain it. Speed is one thing, but long term maintenance is more important.

> use DynAsm (developed for LuaJIT project) for generation of native code

But at the very least, this exercise will ensure that DynAsm will be actively used by a few people. So even if this PHP JIT effort fails, the underlying JIT technology will be more widely understood and hopefully better documented for other projects.

True, however I would argue that having an IR in general makes the code easier to understand and maintain. Especially if you add more optimizations.

> key optimisations such as scalar replacement of aggregates

Can u give an example or link to a relevant article. Context: my area is more of high-level program (e.g. shape) analysis

Scalar replacement of aggregates means replacing an object allocated on the heap (for example, Point p = new Point) by local variables corresponding to its fields (double x, double y)

Removing the object allocation saves time and puts less pressure on the GC. Replacing the instance variables with local variables may also allow the compiler to optimize some things that it would not have attempted to optimize before. For example, storing them on machine registers.

Right, and in a language where you are predominantly using strings, arrays, maps, unless you can remove and optimise through these data structures you spend your whole time allocating them, collecting them, doing lookup in them and you won't have any opportunity to apply other optimisations. You need to be able to understand these data structures at the level of an IR - DynASM or LLVM aren't going to remove a call to a lookup routine for you.

I understand that a JIT engine cant do this, due to speed.

But would be surprised that a LLVM compiler with a custom-designed heuristic for specific optimizations cant manage this.

These problems may be polynomial etc etc, but MOST of the code generated should follow common patterns

I will have to give this some thought.

Thanks for the reply (also GP)

> I understand that a JIT engine cant do this, due to speed.

Most serious JIT engines do! For example V8, LuaJIT, Graal, C2.

> But would be surprised that a LLVM compiler with a custom-designed heuristic for specific optimizations cant manage this.

Rubinius for example tried writing custom optimisations like you're describing and didn't get very far. LLVM is not designed for these kind of optimisations - it understands memory reads and writes, not high-level semantic information about arrays and objects.

In practice, it just doesn't seem to work.

As I say I think it's a bare minimum for making a dynamic language genuinely fast. I gave a lecture about this https://www.youtube.com/watch?v=b1NTaVQPt1E.

There is something to be said about PHP's staying power. The early versions of the language weren't considered "right". Except maybe they were right for the problem at hand.

The way I see it was PHP captured the vector of change, 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).

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't uniformly routable from either end, and well-formed HTML/XML/JSON is just a subset of tag soup.

Worse is better.

PHP also didn't make the mistake Perl did. A shame because Perl tried very hard to make the right thing easy with security.

make the right thing easy with security.

All other things being equal, security is usability[1] anti-pattern. You don't get to make clever hacks (in the original sense) on a secure system.

Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. - Doug Gwyn

[1] at the very least for a power user or a developer

PHP was not really designed, though. It grew accidentally from a templating system. When other systems are said to be more secure, I think it's meant in the sense of not being horrifically broken and routinely injecting untrusted input into namespaces, markup and SQL queries.

Just like C grew accidentenly from a language created to bootstrap compilers and JavaScript was a hacky 10 day solution.

Wikipedia quotes[1] Rasmus Lerdorf as saying: "I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way."

Another relevant quote: "I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say 'Yeah it works but you're leaking memory everywhere. Perhaps we should fix that.' I’ll just restart Apache every 10 requests."

And: "For all the folks getting excited about my quotes. Here is another - Yes, I am a terrible coder, but I am probably still better than you :) "

...which is probably true, but all the more reason to use tools that work properly rather than encouraging me to build more poorly thought-out stuff on top of a broken hack.

[1] https://en.wikipedia.org/wiki/PHP#cite_ref-itconversations_1...

[2] https://en.wikiquote.org/wiki/Rasmus_Lerdorf

Perl's decline relative to PHP is a bit more nuanced. With mod_perl you had to be really careful with global variables otherwise another process could access them in memory. Mod_php did a better job of isolating processes so mod_perl gained a reputation as a security headache which most cheap hosting companies were not prepared to deal with. It's often overlooked that a lot of cheap hosts only offer PHP as a CGI so the benefits over Perl/CGI appear, at first glance, to be minimal but even as a CGI PHP has templating built-in where Perl, Python and Ruby don't. Perl only has CGI.pm when limited to CGI. Sure, you can try to run Perl web frameworks such a Mojolicious, Dancer and Catalyst under CGI but they're not going to compete with PHP since they don't run as drop-in templated pages. Perl did have a PHP clone - HTML::Mason - but it wasn't worth using unless you ran it with mod_perl. That's where Perl lost to PHP.

When PHP gained full OOP support with PHP5 the Perl community was still tearing itself apart over introducing a MOP and which of the dozen Moose clones should reign supreme. That was the final nail in Perl's coffin, at least in it's bid to compete with PHP.

What's that mistake?

Perl 6. You think Python 3 was bad?

Have you looked at Perl 6 recently?

The issue isn't the language which is great. The issue is with the development hell sapping resources from the community

I think it's a given that Perl6 will not achieve the prevalence that Perl5 has.

It's pretty much a given that no language will ever be able to achieve that again.

Ah, of course. But IIRC Perl usage on the web already started to decline (mainly in favor of PHP) before the whole Perl 6 debacle.

I think PHP's strength was also its weakness: an amalgamation of specialized functions thrown into a global namespace without having to bother with modules, CPAN or anything.

If you're an experienced dev it looks like a huge mess but if you're a complete beginner it makes it easier to work with.

> URLs aren't uniformly routable from either end

What do you mean?

Having a single, uniform router (function/class/whatever) is only valid for trivial software. Any non-trivial system is better off with multiple independent URL routers with different semantics.

And yet lots of non-trivial systems have a single uniform router and are just fine with that. So there's that.

I agree with just about all of your post except using Rails as an example of something that burnt out quickly. It was the most popular web framework around for the best part of a decade and is still being chosen for new projects.

Rails was popular among those that never saw such approaches before, like on AOLServer and Zope.

I just kept using Java, .NET and C++, while enjoying their performance, IDE tooling, and whatever ideas they could bring into their web stacks.

Nowadays most cool companies that were pushing Ruby, are on JVM languages.

I think your view is skewed and doesn't reflect what actually happened in the mid-00s.

All views are correct. Look at the number of jobs in cities around the world. Ruby was 1 in California but no where else during that time period.

Skewed from European enterprises point of view.

I only got to know one start-up doing Ruby (not Rails), which happened to rewrite our Perl deployment scripts as a project subcontractor, as they didn't had anyone with Perl knowledge.

Rails was never the most popular framework. But for a certain geography it was. Those were the anti-java crowd.

I think PHP endures because it does one thing and does it exceptionally well. There is no other tool that makes the creation of simple dynamic server side web sites as easy and accessible. Simple FTP/SCP deployment to the server is such a killer feature.

It is also one of the few choices available on cheap shared hosting sites.

PHP was practically "serverless" before serverless was even a thing. You just deploy your code with ftp, rsync, git, or whatever. There's no step 2.

How is syncing your PHP code with the server serverless?

and now you see why "serverless" is misleading.

"serverless" now means you don't run your own web server, you use someone else's.

That's not what serverless means. It means that your code isn't running on a specific server, and between requests it isn't in any kind of running state whatsoever. It's effectively in cold storage until it's needed, then it's pushed to a frontend/edge server and run. Serverless doesn't mean that there's no servers anywhere, but rather that you don't have a webserver or set of webservers that your code is on; it goes onto a webserver when it's needed, and not before.

serverless and compute-on-edge are different things.

Which is what the earlier poster was alluding too. PHP code is stateless and sits there not taking up any resources until it is needed.

PHP hosters have been doing this for 20 years. You have 100s of customers on a single machine, running with a single Apache/PHP process (and child forks), and only if that Host+URL of a customer is requested that PHP code actually gets executed, then completely discarded from memory after its finished.

PHP is very much comparable to serverless. All that talk about bootstrapping costs in serverless is something PHP developers have been tackling forever.

This is a very silly equivalence--you're just glorifying vhosts and method dispatch.

The mechanism isn't the point (and vhosts aren't really either). The point is what a developer (or ops) has to think about when deploying, and in this regard, the default PHP model has a lot in common with serverless.

I don't see a difference there, PHP code can run on any webserver your hoster operaters provided they route the request correctly (I've once used a web provider that would rsync your PHP code to a geolocated DC if they detected more traffic from your region). If this is via vhosts or other routing methods is almost irrelevant, PHP code behaves extremely similar to "serverless" code (except it's often much cheaper).

You still have to deploy to Lambdas.

I believe the post you're responding to was alluding to the degree to which a lot of single-file PHP/HTML is written in a very "serverless-esque" way: no dependencies on an outer framework, and likely scales quite far compared to other languages when run on any number of servers (with the required libraries).

In addition to what you mentioned, with PHP there's no need to start, restart, monitor, or otherwise manage your own daemon. Apache and/or PHP-FPM does that for you.

That's not a PHP thing, it's a CGI thing. You can use any scripting language to do it. Perl was popular but you could use Python or even bash.

Exactly this. I've been doing back-end development for work the last 7 years, first Java then NodeJs and I'm now playing with the Rust web backend (still very early-stage but promised to a bright future IMHO) but my personal blog is still PHP, and so was my wedding's website. Being able to drop a file through FTP on a 2€/month shared server is so convenient!

PHP is the VBA of the web: it's ugly but too useful to ignore.

The other thing it does excellently is that you can take any .html file, renamed it to .php and add some <?php code ?> and it'll work.

In a previous site of mine i had the entire site be statically generated but needed some server-side stuff in one of the pages, so i put something like %%PHPCODEHERE%% and modified the script that built the site to replace the %%PHPCODEHERE%% with the contents of a .php script.

I think PHP had a couple of obvious advantages - it almost had a "first mover" advantage in that it happened to be installed alongside CGI-BIN on shared webhosts way back in the way - plus Drupal and WordPress being PHP projects.

But to me, one of the most significant advantages PHP has is that its documentation is terrific. PHP.net is simple, clear about parameters and return values (as clear as PHP lets it be anyways) and best of all has a terrific comments / examples section for each function.

Better documented is better.

Things may have changed since v7 but historically I’ve not found PHPs documentation any better than any other language.

In fact I remember a few occasions where I’ve ended up going by the advice of the comments rather than the documentation itself because the documentation was either out dated or just plain wrong.

Perhaps not better, but there certainly have been worse.

As for the comments. Yes. But at least they're there, and quite often helpful. Plenty of times I've read other docs where I wished they had commenting but alas didn't.

The comments are only needed because the documentation is often wrong or confused. And, of course, usually most of the comments are wrong too.

Other languages don't need comments because they at least aim to have documentation that's correct.

If you find the documentation wrong or confused please let us know. https://bugs.php.net/ We do our best. I was granted access some ten years ago and whenever I find a confusing page I fix it. I know there has been terrible pieces before but for the last oh five or six years I don't really find anything too bad. Please let us know what you found wrong. Thanks!

I was mostly responding to the idea in an ancestor comment that PHP has unusually good documentation (better than that of other languages), "best of all" having comments.

I'm sure the PHP documentation is getting better all the time! Other languages also have good documentation, though. And as pushpop said in an earlier comment, the reason that the comments were useful historically is that the documentation was not always correct or complete. (Perhaps in part because the the language used to have a lot more unintended quirks?)

I don't see it that way. The comments are there to prevent others from re-inventing the wheel, to share insights, etc. Yes, sometimes that also highlights a "bug" or some other "flaw" but that's the rare exception.

Maybe it would help if you listed some links to language docs that you feel the rest should use as benchmarks?

"Often wrong"? Really? By often, 50% more wrong than right or less? Or more? I can count on one hand the number of occasions I've found the documentation to be incorrect.

"Often" is a fuzzy term and it's used subjectively here. It doesn't mean "most of the documentation" (which would be the >50% goal post you're driving at). It simply means "a lot of the time $OP checks the docs". It might be the case that the only time they need to check the docs is for some of the more advanced features of PHP where errors are more likely to be found in the docs. While you could correctly argue "selection bias", it doesn't still take away from the OPs perspective that it often happens to him.

That has not been my experience but anyway there's a "Report a Bug" link on every doc page.

That hasn’t always been there. Or of it has, then the maintainers haven’t ever done anything with bug reports because there have been errors in the docs for the entire life of 5.x.

I don’t really recall earlier versions of PHP being any better either. So I really don’t think PHP became popular because of the docs.

The other comments about how it was easy to learn and easy to deploy is far more accurate. If I recall correctly, back when PHP gained traction, your main options then were Perl (which understandably confused the hell out of a lot of people), ASP (VBScript / JSScipt and requires Windows NT + IIS so not a popular option) or JSP (Java and at that time was pain to deploy. So not something you’d expect a casual web developer to bother with). So PHP is like BASIC or Raspberry Pi of the 90s web. It was made for one specific job, it didn’t do it perfectly, but it was cheap, easy to learn and just about good enough to get the job done.

Maybe this is true, but by virtue of its popularity and ease of use, PHP has one of the largest selections of tutorials on everything, so that it’s possible to write code by just copy-pasting example snippets.

Maybe within one very narrowly defined field. However move outside of your typical web services and tutorials take a sharp nosedive.

Really the kind of stuff that is well documented in PHP is the kind of stuff that is well documented in most general purpose languages. They are also the kind of problems that aren’t particularly hard to solve anyway.

But this is a moot point because the reason documentation was discussed was because it was credited as being one of the reasons for PHPs popularity. However tutorials wouldn’t exist if a language wasn’t already popular so your comment doesn’t reinforce the point made by the GP.

"it almost had a "first mover" advantage in that it happened to be installed alongside CGI-BIN on shared webhosts way back in the way"

That's a good observation. Because the mod_php and mod_perl Apache modules were much faster and lighter weight than CGI-BIN, and pre-installed on shared hosting, both PHP and Perl dominated the early web days.

Not sure about lighter. Mod-perl at least was quite RAM-hungry if I remember.

Lighter than original CGI-BIN, fork() and exec() for every request.

Faster, yes, but not lighter on RAM usage.

When / where was mod_perl ever widespread? Perl was usually provided via CGI, and php was mostly deployed with mod_php back in the day which gave it a great speed advantage, often at the price of security.

When? Before 2000.. php came after PERL. PHP wasn't a serious language was the general though. ASP was seen as that.. or Java/JSP

I know that Perl was earlier, I've worked with Perl before PHP came around. However, I've never seen a shared hosting environment that offered mod_perl, they were all using CGI.

Might be region specific, I've mostly worked in Western Europe, but even the two NA-based providers I've used back then didn't offer mod_perl for shared hosting.

You could certainly get it on a managed server, or set it up yourself on your dedicated box, but PHP's strong suit was the low-end shared hosting options. It ran anywhere, and usually fast.

I haven't found PHP documentation to be better or worse than the documentation of other languages I've used.

What I dislike about it is the comments that every page includes. Most of them are very poorly written snippets of code from 15 years ago.

If you dislike those comments too, consider adding this to your ad blocker:

    php.net###usernotes

Seriously? On the spectrum of things worth ad blocking, this would never even hit my radar.

I use uBlock Origin and its :style() feature to remove and modify parts of websites that I don't like.

I don't block user comments on PHP doc pages out of spite, I do it because they are very long, making it harder to scroll vertically on the actual documentation.

How does comments at the bottom make scrolling harder?

Not OP, but for me (as a potential example) there are websites that I want to scroll up and down on to view different things, but when you scroll down far enough websites have an annoying habit of auto-opening the comments at the bottom, suddenly tripling (or more) the length of the page, making me lose my spot on the page (potentially) and also making it harder to scroll with precision and/or need to scroll through all this new content I didn't want.

Its a minor quibble on desktop, but on mobile its a really annoying feature because I have to manually scroll with my finger for an age.

Doesn't your browser scroll much faster when you swipe twice in quick succession? I mean while the scrolling is going on, you swipe again and in worst case a third time. I never need to swipe more than three times unless the page is gigantic.

>Doesn't your browser scroll much faster when you swipe twice in quick succession? I mean while the scrolling is going on, you swipe again and in worst case a third time. I never need to swipe more than three times unless the page is gigantic.

Yes, but then if I'm looking for a specific part it has scrolled way past and I need to then scroll back down, sometimes past it, and then scroll back up. Bearing in mind I have to scan the page as it flashes past too.

It's a frustrating experience.

fortunately the date the comment was posted is very prominent on the page

I've actually found many of the comments rather useful over the years, and although I'm not crazy on how old and random they often are, I find them at least worth a quick look.

I've also found that the comments sometimes have very useful notes.

There is the issue of bad advice, but recently I've noticed that there seems to have been a voting system introduced at some point (not sure how long that's been there, I was away from PHP for a good chunk of the last decade), and I think the moderation system is older, so in theory, some of the worst advice should be filtered down/out and some of the best should be filtered up.

> Better documented is better.

I was talking to some kid who wanted to be a developer, and I echoed this sentiment. A complex tool with good documentation is easier to use than a simple tool with bad documentation.

I learned to program through php and the documentation was a major part of that before the prevalence of stack overflow etc

Nah, PHP survived because it wasn't strict, it tolerated a lot of crap. It would process almost anything it can and not fail. Most other languages would error out seriously. Also it's model of running each request as a fresh process eliminated persistent bugs. PHP's documentation is garbage. I say this as someone that has made money handsomely from PHP. :-).

> PHP's documentation is garbage

Birds are Cats.

See, we can all make unsubstantiated claims.

Why do you say PHP's documentation is garbage?

Just one reason is enough. I personally disagree, I think it's great.

the very first first mover advantage was that php was the free alternative to asp, jsp, and coldfusion. all of these languages were built around the simple premise that web devs wanted to inject code into html, which is the way beginners tended to think about coding.

asp locked you into microsoft, jsp was laden with heavy/expensive java app servers and semantics, and coldfusion was a paid product (and eventually locked you into macromedia/adobe).

i think that if coldfusion had the same free+paid model as php, it would have taken the place of php in web history. despite its faults (maintenance and performance, for example), it was easier and faster to learn and matched the mental model of beginners, just like html itself.

PHP started in 1994 and was released in 1995. It was the alernative to writing C code inside the web server (like CERN's httpd) and recompiling the server, or doing everything via CGI. (Yes, hacking servers was a thing. In 1994 I worked on a project in which I did exactly that. This was before Apache and modules.)

ASP 1.0 was released in 1996. The first Cold Fusion in 1995. JSP not until 1998.

Cold Fusion and PHP appear to be neck-and-neck, almost; it's plausible that if Cold Fusion had been free, it might have taken more mind share away from PHP.

Interpolating results into HTML dynamically isn't an idea that originated with any of this software. Prior art is the shell "here document", also implemented by imitation in Perl and other languages. "Here documents" were used in CGI scripting before PHP. (I'm not saying that the shell's "here document" is the ultimate prior art, either).

At your system prompt:

  $ cat <<!
  <table>
  $(for x in 1 2 3; do echo "  <tr><td>$x</td></tr>" ; done)
  </table>
  !

  <table>
    <tr><td>1</td></tr>
    <tr><td>2</td></tr>
    <tr><td>3</td></tr>
  </table>

Part of its staying power is also due to Wordpress. If you're looking for an off the shelf CMS you'll almost certainly be considering Wordpress, Drupal, Joomla, et al.

I could be wrong, but I think the ubiquity of those frameworks/CMSes is rather due to the language's success rather than vice versa. Web hosts made the near universal decision to support PHP as a dynamic language at some point, and the frameworks that were built in PHP then thrived on that. Wordpress wasn't that popular back when I started out with PHP, but PHP was already universally supported by web hosts (hence my learning it). The switch from, uh, I don't know what came before (Perl? Or just a jumble of different languages called by CGI?), to PHP as universal dynamic hosting language, is before my time though.

From my memory (which is not the most reliable source) it was a co-dependent relationship initially. PHP gained acceptance as a language for open source web projects, which lead to the likes of phpBB and Wordpress which in turn lead to PHP gaining even more presence on the web.

I think the staying power of php is at least in part due to the continued success of popular projects that rely on it, whoever was responsible for its initial successes.

As someone who worked in the hosting industry before moving to supporting and consulting on cloud stuff, it's a couple of things.

A handful of projects really are the driving reason for PHP's ubiquity.

Wordpress/Joomla, phpBB/Invision/vBulletin, Magento...

The demand for support for these and some smaller and similar projects really drove webhosts to need to support PHP, and for a lot of the standardized tooling webhosts used, such as cPanel/WHM and Plesk, to support not only PHP, but the automated installation of these projects.

Sure, WordPress wasn't the first - phpNuke, Postnuke, etc, were really popular CMS tools before WP, but if we're talking staying power, you really can look at the stuff I listed as being why it has stuck around.

I could be wrong but my recollection was that PHP initially became the only way to do dynamic pages on shared hosts since it had "safe_mode". At least at my first host, if you wanted to use cgi-bin, you had to submit it to their admin who would read the code and vet it for safety before installing it. While safe_mode probably didn't actually solve that many problems it was a good enough excuse that it meant that admins could allow arbitrary PHP without too much worry.

Similar for self hosted shopping carts. Magento, PrestaShop, OpenCart, etc. There are very few complete shopping cart platforms that aren't PHP.

> There is something to be said about PHP's staying power.

The only reason I use php for my own sites is because I don't want to administer any server and I don't want to be tied to a provider.

PHP is a good fit for this, because it's available at practically all cheap hosting providers (I don't need to administer the server with shared hosting) and I'm not tied to a single provider, because I can switch to an other hosting provider without too much effort.

With other langauges I either have to manage my own VPS (I don't want to pay for managed VPS), or I'm tied to a provider (Appengine, etc.).

Same here, I used to wrestle with PHP, then I just accepted that the best path to make a productive use of my time was just to use it, the same way as you do.

Another thing PHP had was good reference documentation with a comments section for every function.

Systems that are difficult to reason about are difficult to replace.

I once wrote a post comparing PHP to the Zerg in StarCraft. It's ugly as hell yet manages to spread everywhere. Purity of Essence trumps Purity of Form. PHP let you defeat competitors wielding superior technology through rapid time to market. A zergling rush, if you will.

It wasn't right, no. I remember going "WTF" repeatedly even back in 2000, while first learning it and then using it in a commercial project.

It's mostly that everything else was either worse (ASP), or insanely overengineered (JSP), or both (ColdFusion).

Also, with LAMP, you had a stack that was free top-to-bottom. Back then, it still wasn't as common as it is in the industry today, and that especially helped it in the hobbyist and small business niche.

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.

And dont forget about preloading - an OPCache improvement, also available from 7.4.

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.

I think the problem with PHP is that it's a mature language that is aggressively incorporating modern features, yet still is a mess.

It's definitely not my language of choice but I commend them for making good progress from a bad starting point.

What are the messy bits? I know they are there but how is it a mess in your opinion?

There seems to be a lot of "PHP is a mess/garabage/whatever else" hyperbole in this thread with no actual explanations why.

I for one would rather see common utilities move into proper naming and static classing with proper returns. For instance, strpos(string haystack, string needle) will return the position of needle in haystack as an int if found. If not, it returns false. To me, the proper thing in this scenario is to either return an int (even -1 is fine for not found) or throw an exception.

There's inconsistencies in typing of what is returned. There's nothing wrong with loose typing, especially in the place that PHP is used. It's just that the PHP API regularly returns not what you'd expect.

Throw into the mix that the built in simple-functions are all over the place (https://www.php.net/manual/en/ref.strings.php). Seriously, there's str_replace, strpos, and parse_str. These could easily be solved by doing something similar to C#'s naming by changing it to something like String.Replace, String.IndexOf, String.Parse.

On the other hand, they have been moving to frameworks with separate templates and long-lived processed serving multiple requests - just like every other languange. But mod_php and logic mixed directly into the templates were the two main things that made it so easy to get started with, so with PHP moving to the same model as other languages, why not use another (even nicer) 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.

I've had a reasonably good time with Laravel (versions 5.x), although not having a lot of experience with other stacks (say, django), ymmv.

That said, I don't think it's so profoundly amazing as to be worth learning PHP if 1) you're not already somewhat exposed to it or 2) the place where you work doesn't already use a lot of PHP.

do you care about performance? PHP, Go, C#

you'll "figure it out later"? anything else that floats your boat

For majority of backend web project, in 2019, there should be nearly no technical advantage re: one language over another among all the popular ones. (i.e. the ones you listed: PHP, Ruby, Python. I would argue to use pure nodejs over Typescript though. Most people underestimate the dev flow speed it gives you to not to have a compile/transpile step. Refresh and rerun is part of what made PHP so popular years ago.)

In short, use whatever you're comfortable with. If you're super proficient with PHP, keep using it. If Python is that language for you, use Python.

> Refresh and rerun

I don't understand how this isn't easy on other platforms. This is such a huge advantage of PHP that somehow isn't easy to do elsewhere.

I am using pm2 to restart ts-node on file change to get around it but it does take a second or 2 or else I get hit with 502 Bad Gateway on browser reload which is sometimes annoying.

rails also does it automatically but this is not instant and sometimes shows me an old version, so I restart the rails instance manaually in case when I want to make sure which is a sad additional step that no PHP dev ever does.

> there should be nearly no technical advantage

In practice there is. Specifically in regard to parallelism and performance, which is important for any non-trivial application.

You can spin up multiple Python processes or just re-implement in a different language, some nuanced part of the stack that you've crafted to bottleneck(s), or you can just choose not to use it from the start. It's not like you're going to design around the deficiency at all levels.

You'll run into Ruby performance problems very early on without specific knowledge, so people just stopped using it for anything load bearing. My bias against Ruby is limited to PoC programs having memory problems and poor performance compared to virtually identical implementations in other languages, being a cultprit. YMMV.

Perl is hard for people to understand, since every feature of the language is a landmine of obfuscation...php is getting there on it's own, to be fair.

The idea that there should be no technical advantage is ignorant. There are choices that have been made and there's reasons for each. You don't run Python on stream processing with Flink because it's not suited for parallelism. Catching errors like a kafka broker disappearing, in PHP, is almost trivial like in many languages, while Java requires a custom retry method that requires intimate knowledge of how any connector works.

Knowing the languages, PHP has some very compelling strengths, as does Java (performance and safety) and Python (generally consistency of implementation and speed of development)...I still don't understand why I keep running into rats' nests of javascript and other esoterics.

I find that the cost of TypeScript's compiler more than pays for itself with all the other benefits it offers. It's to the point that I can't imagine working in JavaScript without it and I'm less happy working in other dynamic languages when I'm forced to. Refresh and rerun is great when you're developing but offers you nothing when you come back to the code weeks or months later. A good type system has your back even after you've forgotten how everything fits together.

I use Symfony 4 and like it. Clear config organisation, class based controller with logic and route embedded together. Twig the templating engine is nice and doctrine is a very powerful ORM.

I still use PHP a lot.

PHP's problems are largely user driven.

What drove you away in 2004 is likely still there.

The community is still full of people who have no idea.

Laravel is still king.

Noun driven OO is still perceived as a good idea.

But on the flip side, the language has some nice features now and performance got a big boost too.

Still a couple of things missing but it's getting there.

Composer is new since 2004, which is pretty great

Not too serious but I want to stop using a language still forcing me to type semi colons.

CSS -> Stylus. I don't even have to type brackets and colons and not just semi colons.

JS -> JS (TS). Some people may not be aware but you can fully write JS by omitting semi colons. (Except on a few occasions* but I can write a project without one just fine and decent editor will warn you when you're supposed to have one, like IntelliJ and derivatives. Configure it to not prefer semi colons and 1 shortcut key to reformat the code and all stripped.)

PHP -> Ruby, Python, JS all don't ask you for semi colons. Array expression is also too verbose in PHP.

Java -> Kotlin.

HTML -> Pug/Slim/Etc. While there's no semi colon, the verbosity of HTML is insane, people will appreciate the simplicity of template engines like Pug and never look back.

Bash -> Bash. They didn't have one decades ago...

* https://flaviocopes.com/javascript-automatic-semicolon-inser... (some random blog explaining JS semi colons)

I'm a big fan of standardjs. Beats prettier and the rest. Takes more of a go fmt approach.

While debating myself on whether to learn rust or go next I fell into clojure. I'll probably pick go up next and then rust.

> I want to stop using a language still forcing me to type semi colons.

Fuck it, go one step further and stop using languages that expect you to use any formal syntax. Just write down "Computer do this thing! Now, good and bigly like!" and then wait for it to happen.

Of all the fucking complaints about a language "requires semicolons" is the most ridiculous thing I've heard (and no you're not the first place I've heard it, but it's still as ridiculous now as it was the first time I heard it).

> Ruby, Python, JS all don't ask you for semi colons.

Except, JS does require semicolons, it just happens to be able to insert them for you in some situations.

> Array expression is also too verbose in PHP

Array syntax in PHP is the same as in JS: `['foo', 'bar', 'bar'];`. Oh that nasty semicolon is the "verbose" part I bet?

> Array expression

I meant as in

$hash['member']

hash.member

Well that isn't even an Array in Javascript, so already I'm beyond caring what you mean.

I understood that "array expression" meant "associative array", and that the closest equivalent in JavaScript is an Object. But I don't consider myself a PHP guru.

If your team only knows PHP, it's just a small project or you only have the resource to find PHP dev replacement, just use it. Easy to use, online resource is plenty, you won't get stuck unless you want to do a lot of parallel task. Just scraping web efficiently in parallel is kind of a work to get it done in PHP.

Right now I just love having type definitions through TypeScript that you can never have in PHP. (Every variable and hash members starts to have a meaning, which means no mistyping of names, never specify non existing member or method and never use wrong method, as in you can't use numeric methods on string members which happens far too often in other languages and the return value is completely consistent. Say, you have a switch statement, and all of them returns a number but you forgot to add 'default' and TS complains that the method is not always returning a number.)

Ruby as a language is beautiful although it doesn't have the power of TypeScript, the code looks far more beautiful than PHP and if you like how rails works which pushes their rules down to your throat but if you feel it tasty, you might like it too.

PHP is faster than both Ruby [1] and Python [2] and unlike TypeScript the executed code is the same as the written code, no transpiling.

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Like the author of the article said, most websites are I/O bound tasks. This is a CPU bound benchmark.

Like the author of the article also said:

"To improve the ability to execute math faster in PHP seems, at a glance, to be a very narrow scope.

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."

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.

In those long lived processes, a JIT really shines!

[1] https://www.swoole.co.uk/

Know any production grade projects using swoole? I was looking at it in the past but looks very early to trust a business on it.

Afaik the project is pretty old. Never heard of anyone using it in production. There are a few integrations with popular frameworks but nothing production ready because there werent made to live in a eventloop - so, a lot of memory leaks.

Do you happen to have any benchmarks with JIT and libries like swoole?

I thought the same some days ago, but in theory, the output from JIT lives across requests so it shouldn't matter if its a long lived process or simply a normal PHPfpm process.

Also, the usual bottleneck in PHP is I/O.

in long running processes like Swoole, there is no web server running in front of PHP meaning PHP does some more heavy lifting which could benefit from JIT.

That is not entirely correct. Swoole already takes away a lot of the CPU heavy code, like HTTP protocol parsing by providing it in its C extension.

For one of my PHP extensions I benchmarked the C level implementation to be 5x faster than Jitted PHP code: https://beberlei.de/2019/03/25/the_jit_in_relation_to_php_ex...

So no, if your Swoole application does a lot of async I/O and its only in CPU code to delegate between I/O, then it will not benefit from the JIT.

"Long-Running process" alone doesn't mean that its CPU bound.

Article appears to be from the same person that maintains apcu, a very popular user space kv memory cache for PHP. https://github.com/krakjoe/apcu

I believe that he is a contributor to PHP itself.

Joe Watkins is a really nice person and contributed a lot to php including the thread support (php-pthreads) the debugger (php-dbg) and other really impressive stuff.

The nice story here is when he was in financial trouble (because of a bad employer) the community stepped up and donated to him ( https://www.gofundme.com/b9dfcg ).

He has constantly been useful and a positive force of change and any language ecosystem would be happy to have him.

I'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):

1. You may add complexity if you want but the bare metal of web is that you have some printf() like output construct plus a trivial <? ?> interpolation thing. Then who wants more can add more, but this should be what you get immediately for free, without template languages.

2. Languages, even high level ones, should be reasonably fast.

3. Setting up an environment should be trivial.

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 additional constructs to create persistent connections, objects, whatever. But give me this huge garbage collector that is a stateless execution, by default.

5. A set of libraries already included so that for most things I don't have to go and find some solution.

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.

Now, the actual tragedy of PHP isn't that coding in it feels soul-drainingly tainted, but that it was always ‘good enough’ for armies of people. Because, as a result, there wasn't any incentive to add features outside of the paradigm of one-shot scripts.

E.g. there are at least three async frameworks, with barely any adoption―and this new ‘Swole’ one is advertised like ReactPHP never existed, with its promises and everything.

Meanwhile, somehow, the poster notion of PHP's versatility is that it's purportedly just fine for desktop GUI programming, of all things―while being single-threaded (its ‘pthreads’ aren't threads). The topic of UI freezes never comes up in these pamphlets, for some reason.

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't using it for now.

But who knows? I wouldn't have thought it would be as popular as it is now, if you'd asked me 5 years ago.

Love what they've been doing on PHP lately :)

> 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.

Shouldn't we get decent threading built in before we consider most of those? I've hit that wall many times when processing larger amounts of data w/ php scripts. I know about the pthreads plugin but nothing beats a first class citizen like goroutines for go or similar.

Joe (the author of this post and pthreads extension) has been working on a new threading extension in the last months that looks extremely promising and more along the lines of goroutines than Java style threading:

- https://github.com/krakjoe/parallel - https://blog.krakjoe.ninja/2019/02/parallel-php-next-chapter...

Wow, that looks incredible. Thank you for linking it.

I agree. PHP needs 1st party support for proper threading and asynchronous programming.

This would speed up applications more than a JIT would for most.

Though I’m very pleased that this made it to PHP 8

Apart from ubiquitous cheap hosting another big factor in PHP's early success was the numerous magazines pumping out "Build X with PHP and MySQL" 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 "Philip & Alex's Guide to Web Publishing" 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.

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't care enough to know anything about PHP 8. Why is the author insulting me with the intro?

I felt the intro was a little off too. I hadn't even heard of PHP 8 until today.

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't this duplicate the effort of HHVM?

Nope! As of last year, HHVM no longer targets PHP [1]; instead, it targets a Facebook-specific variant of PHP called "Hack". It will still run some PHP code, but that's on its way out.

Even better/worse, PHP 7.2 with an opcode cache can actually outperform HHVM on many practical benchmarks [2], and 7.3 is faster still.

[1]: https://hhvm.com/blog/2018/09/12/end-of-php-support-future-o...

[2]: http://web.archive.org/web/20180305000053/https://kinsta.com...

For a second I read that as "PDP 8..."

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

Web PHP projects that want to move some stuff out of a web request? Like delayed_job

Web PHP projects that want to add some command line programs for doing maintenance tasks etc

Real time processing of Garmin fitness data takes a lot of cpu. We had to use a c module to handle this can't wait to try php 8.

Don't believe it. Maybe in SV it's out of grace, but it gets plenty of use.

I already submitted that: https://news.ycombinator.com/item?id=19531611

Reply on news.ycombinator.com