Hacker News Reader

Comment by mojuba | Hacker News Reader

Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language?

PHP is not a likable language but it's probably not going away any time soon. Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course.

That, and also the fact that it may be pretty much the only dynamic language in use today with ARC and not a GC. Funny how PHP devs are often unaware of this.

Anyway I wish the language at least evolved faster and we wouldn't wait for 8.0 to have global `const` definitions instead of the archaic `define()` for example.

View on HN

> Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner.

I don't see that as its biggest killer feature. In fact most projects built on PHP using a framework won't use the feature, as every request will be routed through a front controller. This has been true for at least a decade.

I think the killer feature of PHP is its shared-nothing architecture, tear-down at every request (or every x requests if you're using php-fpm) which has proved remarkably successful as it is so resilient.

It's a blessing and a curse. Makes it amazingly easy to start with, which is how many PHP developers started (with perhaps folder root index.php rewrites and that's it), but later it makes it confusing, especially if "it always worked" for you, when you want to do dynamic routing.

I see the same pain for some next.js devs these days, even though it does allow parameters in roues in [name].js file form, I saw some people generating routers from file trees and finding it an acceptable compromise. Well, each to their own, I guess.

> I think the killer feature of PHP is its shared-nothing architecture, tear-down at every request (or every x requests if you're using php-fpm) which has proved remarkably successful as it is so resilient.

I agree. Shared nothing is definitely the killer feature.

Even if php-fpm is tear down at every x requests, each request still starts afresh in which each needed PHP file is required and loaded again. This is not slow because of opcode caching means that parsing etc. does not need to be done afresh. PHP just pulls from the opcode cache. At the end of the request the request is torn down. The interpreter instance might be reused again for performance (though that may be torn down every x request also as you implied with php-fpm for instance).

When you want to find out why something did not work in PHP you just need to go back to the start of the request and work your way from here. With a stateful system like Django (Python) or nodejs (JavaScript) you need to worry about the state of the full server in addition to what happen in a specific request.

This is an ideal model of course because large PHP implementations uses caching (in things like redis) to speed things up and the cached state could be the one introducing a bug. However, in practice, PHP tries to put in most of the state in a relational db so debugging a PHP script is much simpler due to this shared nothing feature.

Could you elaborate on the shared-nothing architecture?

I found this article a while ago

> Every web request starts from a completely blank slate. Its namespace and globals are uninitialized, except for the standard globals, functions and classes that provide primitive functionality and life support. By starting each request from a known state, we get a kind of organic fault isolation; if request t encounters a software defect and fails, this bug does not directly interfere with the execution of subsequent request t+1.

> An individual web request runs in a single PHP thread. This seems at first like a silly limitation. But since your program executes in the context of a web server, we have a natural source of concurrency available: web requests. Asynchronously curl’ing to localhost (or even another web server) provides a shared-nothing, copy-in/copy-out way of exploiting parallelism. In practice, this is safer and more resilient to error than the locks-and-shared-state approach that most other general-purpose languages provide.

https://slack.engineering/taking-php-seriously/

How does this differ from how other web frameworks work? I thought almost all of them are shared-nothing.

In its early years up until around 2006, PHP was mostly "HTML on steroids", that is, an HTML preprocessor with lots of goodies like "batteries-included" DB access, form handling, image processing, text processing, all accessed via a single Apache module. You simply rename your .html file to .php, and put some magic between "<?php" and "?>".

Then came along templating engines like Smarty, and they introduced a new templating language for a language that was already built for templating. For some reason, "<?= $foo ?>" was considered much worse than "{$foo}".

It was one of the first freely available languages that allowed you to do image manipulation so sites like DeviantArt would use it.

> For some reason, "<?= $foo ?>" was considered much worse than "{$foo}".

A stigma that remains to this day, even though the spec is very clear about those kinds of short tags and the flags that affect them. PHP developers are absolutely terrified that some imaginary environment flag they have control over is going to brick their application, but are happy to bring in an entirely new templating language as a dependency instead. I'm sure Smarty was borne of a need, but I was never sure what it brought to the table except different tags for existing features.

That's exactly what has puzzled me for a long time: a language with HTML templating as unique selling point needs a templating "engine" after all?

smarty.net has a pamphlet up there where pros/cons (but actually only pros) are discussed [1]. Failing to understand that "<?php ...>" syntax is a SGML processing instruction with well-defined ways to embed into a hosting markup language like HTML, they go even so far as to say

> Another issue with PHP tags is that they share the <> characters of HTML tags. In the application code this isn't an issue, but mixed with HTML, <?php ?> tags are a maddening process to tell them apart from the HTML tags. This also blurs the line between application and presentation separation since any PHP logic can be injected into a template.

Yeah no, now you need new escaping syntax if you ever wanted to have verbatim {$whatever} in your HTML.

Notably missing is a discussion about HTML-aware, injection-free templating such as for preventing {$bla} expanding into <script>alert('Pwnd')</script> when sourced from user input, which is what SGML and other HTML-aware template engines can do, and which in the name of everything that's holy should've been implemented in PHP 2 to save the web from becoming a botnet.

[1]: https://www.smarty.net/syntax_comparison

>and which in the name of everything that's holy should've been implemented in PHP 2 to save the web from becoming a botnet.

Hack did this correctly with XHP templating. Unfortunately, Hack was killed by PHP7, and of all the features it took from Hack, context-aware native templating was not among them.

Its concept of "one endpoint is one script" is one of its biggest killer features

Is that still a thing in PHP world? I recently ended up working on a 'modern' PHP project using Laravel and it was all routers and views and models and auto-generated scaffolding code, just like Rails and Django. There was no sign left of that 'old' approach.

It's not. You usually hear that kind of reasoning exclusively from people that last interacted with PHP decades ago.

There's a lot of popular examples of more or less abandoning the old ways, but the old ways still work.

I'm of the strong opinion that modern PHP with frameworks and auto-include and a ton of modelling is the wrong way to do it, but everyone else can do it that way, and I can still do things the old way and I can be happy.

PHP has this amazingly zen model of computing. At the end of the request, everything is thrown away to start fresh. This means anything you don't output is garbage. I don't think it makes a lot of sense to make sculptural models of your data and page structure only to throw them away. It's best to keep things simple.

There's some times and places where it makes sense to use more features, but starting with a kitchen sink framework makes it very hard to get simple where it's needed, but you can always pull in a little bit of something more complex into a simple thing.

You know, I kind of agree with you. When using Laravel I felt a lot of the time I was fighting against PHP rather than leveraging it. Back in the 'old' days when I was using PHP4 in the way you describe, PHP made sense as a choice compared to, say Python, for certain use cases. Today, I have a hard time coming up with an argument why using modern PHP and Laravel makes more sense than Rails or Django. Maybe we need a post-modern PHP movement focusing on bringing PHP back to its roots.

> Today, I have a hard time coming up with an argument why using modern PHP and Laravel makes more sense than Rails or Django. Maybe we need a post-modern PHP movement focusing on bringing PHP back to its roots.

Over Django: - Because if not doing SPAs, it provides infinitely better tools for the frontend, such as an integrated assets pipeline, a good template language with componetisation support - Because it is faster - Because during development every change is not a restart - Because it has an integrated queue system - Because you have popular frontend solutions such as Livewire

The only better thing I've found in Django is the admin.

Over Rails: - Because it is faster - Because PHP is far, far, far more popular tan Ruby - Because it has integrated authentication - Because it is easier to hire for

just some reasons from the top of my mind. I don't have a ton of experience with Rails and I think it is still great, but IMHO Laravel is better. I have worked with Django for about 10 years, and other than the Admin, I don't miss anything when working with Laravel. Language wise PHP vs Python is just syntax, I don't care as both ecosystems are pretty healthy.

PHP is either a flawed scripting language for some or a "poor man's java" for others.

I had to learn JEE(JSP,JSF,CDi,JPA) for some project lately, so now I understand a bit more why Doctrine, Synfony and co are the way they are, coming from Go, Ruby, Python and JS... Well I prefer just writing some JEE stuff rather than using a PHP framework in that case, because I realized the Java cargo culting was just insane in the PHP community and how PHP is poorly equipped to replicate that JEE stack...

PHP isn't going away though, billions of PHP scripts out there to maintain, and CMS are built in PHP mostly because of hosting providers still defaulting to Apache servers because cost.

Nothing is too little too late though, when I read about the evolution of Java, I realize I'm lucky to suffer through it today rather than 15 years ago...

> Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course.

JSP on Tomcat works mostly the same way. and nothing prevents anybody from using python or ruby, (or C++) in FastCGI mode. PHP has that whole "templating stuff" though.

> PHP has that whole "templating stuff" though.

That might be underestimating the feature, it was very much the core proposition of the language and likely why it's so well suited for web applications.

Yes, that's exactly why I'm pointing it out. Neither Python or Ruby have(or had) that.

The big guys, who know what they're doing use PHP because it makes devops stupid simple. Throw it on the server, its ready. That's always been PHP's killer feature.

Is it? Last time I used PHP (around 5.x-7.x) it was exactly the other way around. For production you needed php-fpm, nginx, opcode cache... it was a nightmare compared with go or even java. Is it better now?

I think the thing is, you install those once, and then you can run an infinite number of websites.

They also share the same resources, so even your little blog can take as much (or more) traffic than your production application.

Does anyone really deploy PHP directly on servers still..? Running it in a Docker container is the simplest thing possible, runs anywhere, and has top-notch performance.

I meant Docker. The fact that I needed multiple processes (nginx+fpm) made PHP setup tricky compared with e.g. Java with embedded server.

I know what you mean; that has been a problem in the past. In case you have to again, I'd recommend looking into either Roadrunner or Swoole. That makes it possible to have your application run more or less standalone in a single container, hosted by a native application server. This boosts performance incredibly, and exposes a single HTTP port, as it should be.

For Symfony: https://github.com/k911/swoole-bundle

For Laravel: https://laravel.com/docs/8.x/octane

aha, that looks good. Thanks

> The fact that I needed multiple processes (nginx+fpm)

I believe you can have fpm listen on TCP and run nginx in another container if you want, although I haven't tried it so I can't vouch for it.

Yup, tried that. It’s a bit too complex imho but works too.

The opcode cache is built in now. A webserver and php-fpm are still a good idea.

More funny is how developers keep being unware that ARC is a GC algorithm implementation.

Then they tell learning CS theory is not required.

I do know ARC is also a garbage collector, but is there an agreed name for the other GC's? There is a significant difference and performance implications with ARC vs. the other ones, that's what I meant.

You mean being the worse implementation of any GC algorithm, unless it makes use of tracing GC like optimizations, e.g. hazard pointers with deferred collection? Maybe.

Naturally there are agreed names for other GC's, that is what widely acknowledged books in CS like "The Garbage Collection Handbook" [0], or papers like "A unified theory of garbage collection" [1] go about describing.

[0] - https://gchandbook.org/

[1] - https://dl.acm.org/doi/10.1145/1028976.1028982

PHP uses a garbage collector since version 5.3 that was released around 2009/2010.

(Repeating myself) PHP's garbage collector is ARC.

How many GCs are we at with Java?

> pretty much the only dynamic language in use today with ARC and not a GC

Python uses RC, with GC available but only used for cycles.

Slow change is good for small projects that you want to build once and use for decades without much maintenance.

A language that uses archaic syntax with dollar vars, semicolons, is pretty verbose itself may die before it evolves into something sensible. Not that I believe PHP will die any time soon, but just replying to your "slow is good".

There is no real producticity gain through not having semicolons and somewhat leaner syntax. That was never the bottleneck: ecosystem, libraries are.

There is a real productivity gain when you remove all things that cause a mental tax on reading. After Swift I don't want to look back at the C-like syntax languages any more (just that occasionally I have to).

You may think so subjectively. But there is no objective study whatsoever that would support that.

> A language that uses archaic syntax with dollar vars, semicolons, is pretty verbose itself may die

Careful there :-) Modern javascript has semicolons and is introducing pretty horrendous syntax for private variables (an octothorpe) and possibly for the pipe operator (percent sign, was it?) and for tuples and records, yet is showing no signs of dying.

I have never written JS with semicolons after 2015 idk why you are saying Modern JS has semicolons? I simply didn't get it. Am I missing something.

I mean, it clearly has them; it's part of the syntax. You can skip them, and the parser will insert them for you; but the language has them.

yea but its optional so does it matter? In PHP its compulsory, right?

Sometimes the extra options can produce unexpected problems. For example, in JavaScript, this would return nothing and may result in an unreachable code warning:

  function go() {
      return
          5 + 3;
  }
  console.log(go())

Since semicolons are optional, it's treating "return" as its own statement and "5 + 3" as a separate one.

There are no hidden gotchas like this in PHP though since semicolons are always used:

  function go() {
      return
          5 + 3;
  }
  var_dump(go());

This will return int(8).

I do like dollar vars, because I know immediately when it's a variable and don't have to rely on syntax highlighting.

It's still in major use across the industry so I don't think it's too little too late. Maybe late, but not too late. I think it's pragmatism is partly why it's still so popular. No need to rush to the next best thing as PHP is perfectly capable of taking you from side-project to enterprise software with millions of users.

There is a garbage collection:

https://www.php.net/manual/en/features.gc.php

> This section explains the merits of the new Garbage Collection (also known as GC) mechanism that is part of PHP 5.3.

> First of all, the whole reason for implementing the garbage collection mechanism is to reduce memory usage by cleaning up circular-referenced variables as soon as the prerequisites are fulfilled. In PHP's implementation, this happens as soon as the root-buffer is full, or when the function gc_collect_cycles() is called. In the graph below, we display the memory usage of the script below, in both PHP 5.2 and PHP 5.3, excluding the base memory that PHP itself uses when starting up.

PHP's garbage collector is ARC, unlike any other dynamic language that I know of.

ARC is more performant but can introduce memory leaks via circular references, which is probably not a big problem for short-lived scripts anyway.

Sounds optimal for PHP where 99% of scripts are short lived.

Which is perfect for a HTTP request.

I'm not sure if you did not read what I quoted, or I misunderstand something.

Yes, PHP has reference counting, but it also has specific process that kicks in to clean up circular references.

How is it more performant? If you have multiple threads than you will get serious atomic operation or other synchronization overhead.

PHP is share-nothing architecture. Nobody really uses threads in mainline PHP.

Whole class of problems around multi-threading, mutexes, dead locks etc. are really foreign to PHP developers.

Yeah, I should have mentioned that in the general case RC is not more performant (otherwise threaded managed languages would use it).

Python uses ARC plus a tracing GC for dealing with cycles, same as PHP: https://devguide.python.org/garbage_collector/

Perl uses ARC with no tracing GC, so you have to handle cycles yourself: https://www.perlmonks.org/?node_id=1173079

TCL uses ARC, and apparently doesn't need a tracing GC because it is impossible to create cycles in it: https://wiki.tcl-lang.org/page/Garbage+collection

ARC is not more performant, it's more deterministic. "regular" GCs have better throughput. RC in general also handles other resources (like files) a bit better than GC.

PHP has a GC since 2009 (version 5.3). Its goal is precisely to collect reference cycles.

> Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language?

No. While PHP won't be the language of choice for academia or some new hipster startup that wants to woo junior engineers with the promise of "we're using the latest cool shit", the trio of PHP, Java and .NET with their associated ecosystems has managed the fine balance of evolution speed between uprooting everything on the regular (like NodeJS which went through at least three major build toolings with zero compatibility and the Javascript language itself with at least four ways of creating modules) and becoming a live fossil (like Perl) pretty well.

A typical Java project has way more complexity (and confusion and sadness and pain) than your typical node.js project in the enterprise world. I have stomach cramps thinking about the stuff my eyes have seen. .NET is not innocent either.

For PHP, just look at the Drupal, Joomla and Wordpress codebases to see how many ways there are to include files. For a current example, see the hate Laravel receives on how it does DI from Symfony-likers. There's also the Laminas (Zen) crowd going all-Java.

If something is popular, there WILL be many ways to do the same thing. Look at how Python is evolving.

> A typical Java project has way more complexity (and confusion and sadness and pain) than your typical node.js project in the enterprise world.

Personally, in my career I've seen and worked with projects in SAP, Java (Tomcat), .NET, PHP and various JS-based projects - of all these, the JS projects had the most variety of bullshit (although SAP still gets the cake for "stuff I'll never willingly work with again" simply because how mind-boggling the entire environment is).

At least it's easy enough to get a bunch of Java developers to agree on what package manager and build tool they will be using - it will mostly be Maven and that's it.

For a nodejs project, you will first have to decide on the framework to choose, then on the build tool because not every framework works with every build tool, then you will lose a lot of time until Webpack finally does what you want, and in a year half the libraries you use will be unsupported.

Are you sure? There's gradle and others. Also which server? Wildfly, jboss, jetty, glassfish, soemthing else? Which java distribution? Perhaps you want to use vertx, tapestry, undertow instead of good old Spring? Maybe Grails? Which testing framework? Some people love their JSF (yes!), is it still really, like for real supported? Should you use JSP? I mean from configuration to configuration so much changes that I don't touch undockerized Java projects. It's just too much work. In one case one experienced Java dev struggled to get me a working dev env for a week. Even IDE extensions sometimes play a role in the build in Java world. Give me a break.

> That, and also the fact that it may be pretty much the only dynamic language in use today with ARC and not a GC.

Python and Perl use reference counting too. Ruby, Lua and JS (at least v8) are GC'd. PHP isn't unique in that regard.

I think that’s my biggest problem having moved from PHP to Typescript. I just expect my language to have certain features now, and while PHP is catching up, it still isn’t there yet.

And even if they do, what then? It’ll just be feature parity, so there’s no need to switch back either way.

Isn't ARC over a GC evident in PHP with its opcode cache? I don't think I have run into a PHP dev who thinks PHP has a GC

the very fact that you don't have to think about memory management it means that there is something else taking care of it. Call it GC or otherwise, no PHP dev will be think about memory management at all, unless they are building some long-lived, large data processing

> no PHP dev will be think about memory management at all

Not nowadays, for sure. In 2009-2010 it was still something to keep in mind, and careful array handling was common so the it wouldn't baloon hundreds of megabytes for not so large data structures. I wasn't working on big data (tm) at that time, but running database imports via ETL processes in PHP required a few optimization passes.

I really can appreciate nowadays the huge memory and performance improvements that PHP went through from the 5.x days to the recent 8.1 release.

Sidenote: Shout outs to Nikita Popov who came to the scene and revitalized the language for me back then, for his proposals and features implemented in a time when PHP felt stagnant language wise https://www.npopov.com/aboutMe.html#accepted-php-proposals

i've been working with PHP for almost 20 years and to be honest i've never had to think about memory management until the last 10 years or so and only in case of long running processes (e.g. cronjobs)

Reply on news.ycombinator.com