The best feature of PHP has always been that it's "serverless", or in more historical terms, stateless. The application itself doesn't have to worry about keeping a server running or making sure it doesn't leak memory or crash. Blast radius is limited to a single HTTP request, just like in AWS Lambda.
The downside is that the PHP service environment does't provide much of a runtime framework, so the PHP application itself needs to perform a huge amount of bootstrapping on every request (this builds up over time as you add stuff to the application). Comparing this to AWS Lambda with e.g. Node.js, Lambda can keep a lot of stuff pre-initialized in memory, and usually just directly execute a handler function. Also things like URL request mapping are externalized to a separate API Gateway. There used to be a lot of tweaking and running separate caching modules needed to make PHP bootstrap fast enough.
I've always been sad that AWS hasn't developed a fully supported PHP backend for Lambda. Combined with a lightweight HTTP gateway, it could be a nice way to keep running legacy apps like WordPress in modern serverless environments, without worrying about server costs and maintenance. You can do it yourself with Lambda layers, but there will be all kinds of small mystery timeouts and problems you have to deal with.
> When I read comments like this I always wonder who is out there creating stateful HTTP applications?
As a benefit of PHP this isn't a new thing, and usually what is meant isn't that people are deliberately creating stateful HTTP applications (thought they may be!).
What it normally refers to is the way that with PHP every request gets a totally new instance of the interpreter to run in, as it is basically started up from scratch to service that one request, does it's work, then disappears again. There is no possibility of bleed across requests or of accidental shared state.
Whereas with Node, Go, C# etc, there is (by default) a long-lived 'server' process that handles all incoming requests and so doesn't have that automatic request segregation but instead relies on code (framework and/or application).
To rephrase, with PHP there are multiple requests each of which get their own one-shot instance to run in (guaranteeing segregation). With most alternatives there is one server instance which handles multiple requests and something in the stack somewhere has to manage that segregation.
PHP maps many requests to many servers. Versus many requests to one server. But of course this is all very much a simplification.
- Are long-lived per-process in-memory read-through caches "stateful"?
- Is per-connected-websocket topic subscription state "stateful"?
In both of these cases, nothing breaks when you hard-kill + restart one of these processes. People who add these things to a web-app backend don't usually think of themselves as making the backend "stateful."
But nevertheless, truly "stateless" technologies like CGI or PHP are defined by how they don't have access to things like this.
I think the opposite side of the spectrum in the sense we're talking about "stateless" here would be something like node.js, or Go, where a single "process" is kept alive at all times and responding to every request. In these non-stateless runtimes if you're not careful you could leak information from one request to another, or some unhandled errors or exception terminate not just the request that caused it, but all other request being concurrently handled at the moment the error happens.
Ok, I have avoided node and Go. Does their web interface allow your application to share data between instances of your business code? That is a very unusual interface. AFAIK, Java, Python, Ruby, Haskell, and Rust standard servers do not have this on their main interface, and usually require exploiting their cache systems to achieve it (what you can do on Apache too).
Or are you talking about exploring the OS primitives to share data between instances of your code? Because avoiding that shouldn't require a lot of care, and PHP has basically the same capacity.
Any runtime that has the concept of "thread locals" or "thread safety" have this sharing problem, no need to exploit y anything. Of those you mention I've worked with Python and java and their runtimes do have this problem (or feature, depending how you look at it). In python for example if you import a module level variable or instance and you modify it's value on a request, you can read it from another request that lands on the same thread. Same with java. I don't know the others you mention but probably are the same as that's how most runtimes work.
You can't do that in PHP, you need to explicitly write to redis/memcached/file/database to be able to read values from another request.
For all intents and purposes there is only one instance of your business code. It is a single process. And you do whatever you want.
However, this is not a problem at all. In Go you would have to get out of your way to share information between user agents just like you would have to do in PHP.
Intentionally writing to and reading from a global variable is the exact same as intentionally writing to and reading from your MariaDB instance.
I have no clue why you would render this process problematic. Maybe in Python everything is a global?!
At least I wrote a lot of Ruby on Rails and Django (Python) applications back in the day. They always run their own server. I.e. there is no isolation between the server and between the application code.
Nope, those are guidelines for creating your own PHP runtime for Lambda. It doesn't support PHP natively. The difference is that you need to maintain and debug your own runtime instead of paying for AWS to do it.
I'm a daily PHP programmer and I'd pick it any time for server stuff...
But wow, this is not a convincing article at all. It's just an opinion with nothing to back it. If this was on a forum, I'd think it was a waste of space and ignore it.
But a blog post? And someone shared it here? What were they thinking?
> But a blog post? And someone shared it here? What were they thinking?
I honestly wasn't expecting anyone to care about my opinions but shared it here on the off-chance there would be an interesting discussion about PHP/C#. Though, it mostly just to seems to be people complaining about my opinions, so maybe that was a bad idea.
Why would I ever be inclined to use PHP again? It’s only okay for web servers, but with a language like Go or Python I can do a lot more with them.
PHP was an utter mess. Has it changed? I don’t care. It broke my trust and I’ve moved onto languages that are more thoughtful and general purpose. Returning to PHP would feel like returning to an abusive relationship
The Python 2.x to 3.x transition was also quite messy and long-winded but now 3.x rules the roost. Recent and coming PHP versions have done and will do away with much of the evolved mess that the language accrued in the decades. Performance is OK, deployment is easy, it is nearly universally supported, the build system is quite a bit more sane than the spaghetti-ball-like mess around node and friends.
It is possible to use PHP for CLI apps as well but this is a bit of an afterthought:
if (PHP_SAPI == "cli") {
# CLI-code goes here
exit();
}
It is the right tool for a lot of jobs - not for all jobs but what language is?
...which also have their problems, e.g. text encoding handling in Python 2.x was horrid and full of traps. This is better in 3.x, problem mostly solved. The same goes for many of the warts in PHP which have been fixed or are scheduled to be fixed in 8.1 and later. Given a choice between a world without PHP and one with it, warts and all, I choose the latter. Not because of its elegance or correctness or performance but because of its utility. In this respect it is a bit in the same situation as Bourne/Korn/Born_Again shell, languages which surely could be better in many ways but excel in just being there when you need them and for the purposes you need them.
The language at hand is often the best language for the job, just like that phone camera in your pocket is the best camera to snap that shot of whatever event you just happened upon. Sure, it would have been better if you could use a DSLR on a stand, shooting raw to be processed in some fancy tool but that DSLR and stand and tool generally complicate matters far more than they add in quality. Sometimes this is worth it, often it is not.
For one, PHP generally outperforms Python by a large factor.
Also, to claim trust has been "broken" is just weird.
Every software engineer should be well aware of the horrible mess that is the PHP language even if they had just had a cursory glance at it.
In any case. I would never pick PHP on purpose either. Even if it was the most appropriate tool in a given situation.
It simply makes my blood boil, and I don't care if it's irrational.
Both development team and the community matured and learned a lot. The language lost a few of its footguns, but preserve a lot for compatibility reasons. The best practices evolved in good ways, but the old documentation is still around.
So, yes it changed. If it changed enough is a different question.
If we strip whitespaces in the merge sort version you provided and apply same formatting it becomes a 30-liner https://pastebin.com/KmWBMC0M vs 31 lines of PHP.
How do you measure productivity and how can you prove that productivity in PHP is higher than in C#? In my career language was never a productivity bottleneck. Good quality frameworks and libraries do make a big difference on the other hand.
Neat, I did not know you could use Nginx Ingress directly with FastCGI! That was worth the read alone.
I've certainly warmed up to PHP over the last couple of years as I've been maintaining a couple apps, and while it's nowhere near my favorite language, I do think PHP gets an unfair bad rap because of historical terribleness.
Call me an elitist, but I'm a big fan of well thought out languages built from the ground up by smart people like Java and C#. PHP is more of a hodgepodge of functionality glued together. However, I can appreciate PHP's simple way of getting server-side processing up and running.
Honestly, I can't care less about "languages". To me they're just syntax. And for all the kind of web applications I've built, the performance has never been a big concern over other stuff such as building features, fixing bugs, development speed, etc.
What does matter A LOT for me is the ecosystem, the tools, the editor support, the libraries, the frameworks, the community, etc. And PHP does GREAT at this. I'm using Laravel nowadays and it feels like a better Rails, with better tooling, better editor integration, more people using it, more community, more libraries, etc. Is the language a bit uglier? yes, but I don't care about the syntax, everything else matters a lot more to me.
I wish I could downvote links on HN. I wouldn't flag that, because it isn't something outrageous, it's just a bad post that doesn't even try to substantiate its point in any meaningful way.
The downside is that the PHP service environment does't provide much of a runtime framework, so the PHP application itself needs to perform a huge amount of bootstrapping on every request (this builds up over time as you add stuff to the application). Comparing this to AWS Lambda with e.g. Node.js, Lambda can keep a lot of stuff pre-initialized in memory, and usually just directly execute a handler function. Also things like URL request mapping are externalized to a separate API Gateway. There used to be a lot of tweaking and running separate caching modules needed to make PHP bootstrap fast enough.
I've always been sad that AWS hasn't developed a fully supported PHP backend for Lambda. Combined with a lightweight HTTP gateway, it could be a nice way to keep running legacy apps like WordPress in modern serverless environments, without worrying about server costs and maintenance. You can do it yourself with Lambda layers, but there will be all kinds of small mystery timeouts and problems you have to deal with.