PHP's evolution since PHP 5 has been substantial, and I think this is a real problem. As someone who learned the language years ago, the pace of change (generics, attributes, match expressions, typed properties) makes modern codebases genuinely difficult to follow.
I suspect this affects many developers who cut their teeth on PHP but haven't kept up. The language has become a different beast, which is a strength for the community but a barrier to re-entry.
IMO, newer PHP is still very readable. I programmed with C++ for a decade, but I can safely say that I cannot understand a modern C++ code base anymore.
C hasn’t changed all that much, and someone who coded in C99 would take about 30mins to catch up to a modern C23 codebase’s changes. Famously so, as conservatism to change is the main friction in the community for about two decades now.
If you pull out examples of the earliest C, sure, it looks weird. But that C was already obsolete in 1989. Since then, it’s had a minor iteration (e.g. five-eight additions/modifications) every decade-ish (99, 11, 17, 23). Has it changed? Sure. Can it be compared to the iteration and speed of things like C#, Java, C++, etc? No way.
I am quite sure many people would fail Pub Quizzes related to C, when taking into account the whole language alongside compiler extensions, regardless of the compiler.
To learn all of the common GCC and MSVC extensions would make up a fraction of the language features of C# or Java. You’re really overstating the complexity to make some invalid point.
“Actually, one of the most notoriously conservative and simple (in feature set) languages is really super complex and has evolved a ton because it has _Generic and varargs now, and __packed__ exists as a compiler feature.”
And to further double down, that minor evolution is over 36 years (arguably a decade longer, but I’m being generous with your argument). Not the 12-16 years (depending which 5 point release you wanna start with) that PHP has morphed into an entirely different language.
I think he's thinking more along the lines of PHP 5-8.5
That version 1-latest is understandingly highly different, but these are all decades old languages, which barely changed for some time, but are now all introducing new syntax.
Which I think makes sense, but it's obviously going to leave 9-5 devs behind that don't particularly care for coding and want to invest as little time as possible into their language knowledge.
Most likely this can be said about a lot of languages, most languages are being maintained and improved. I am an hired expert in Java and I needed to explain some new languages features to some colleagues that have been introduced recently, I only mention them if they actually improve readability though.
I think PHP might be slightly different than other languages as a huge amount of people use this to create their first website as a hobby.
It has nothing to do with being “too hard”, and everything to do with not making sense to the type system. PHP is weakly-typed and heavily reflection-based (so everything is aware of it’s and each other’s type at all times).
Adding generics to PHP would make CS fundamentalists somewhat happy, but do nothing to change the fundamental design of PHP nor offer any of the traditional benefits that generics offer to strongly-typed and compiled languages. And would be a massive headache to implement, while bulking an already heavy VM implementation.
Exactly. The type system was never built for anything even slightly more complex. Its basically annotations for primitive types and classes. PHP has always had an weak type system, so adding generics will most likely never happen.
> Adding generics to PHP would make CS fundamentalists somewhat happy
PHP has really only one collection datatype (the infamous array), so having generics would be tremendously useful, as an example you cant return an typed array from a function, witch is just really bad.
For an counter example, Python managed to do this, while also being a dynamic language, although having a stronger typing than PHP.
TLDR: The PHP compiler isn't really suited for the job, it would introduce a lot of complexity to an already complex codebase and the memory/performance hit would be substantial.
Yup, this was pretty much what i recalled. The typesystem, while being incredibly "unintelligent", somehow still is so complex that generics are not going to happen.
I still love PHP. 23 years ago we created some encryption software for it and it is still going. I also run a PHP newsletter. There's still a strong community of people and whilst there are other languages which I also use (Python, Node.js) I still find myself gravitating towards PHP for fast and simple work
The only issues I have. is that this is a 'double edged sword' in that PHP has become far more complex since the launch of PHP 5 and so it isn't as easy to understand from scratch as it used to be
A lot of people are too proud to be associated with PHP. I am ready to admit that know nothing about the language except that a lot of people make cool things with it.
My favourite PHP product at the moment is BookStack (https://www.bookstackapp.com/), a really good wiki. I run an instance for my family and it's great.
But there are loads of things. And I notice that many of the sites I like using...are built on well maintained PHP stacks.
PHP is a very pleasant and straight-forward language to work with. I enjoyed my time working with it, though I did also see quite a lot of very poor code.
I think the danger with PHP is more its ability to easily cause *very bad things*.
This would partially be poor training (my University literally taught PHP with SQL-injectable examples), and I think the language itself making it very easy, such that less-experienced developers using it - most of them, early on - don't realise what's wrong until it's gone wrong.
With PHP being such an early tool online, and the above properties existing, it earned a reputation for being insecure and bad.
At least in my experience, the early years of PHP was lacking more enterprisey users; back then there was a small revolution when RoR came out and introduced the MVC pattern to a lot of (web) developers, who didn't have as opinionated a pattern / architecture up until then.
During that same period, there were a lot of mediocre tutorials and documentation online, including on the PHP website itself which allowed people in comments to post code examples, but as far as I know there wasn't a lot of moderation on those.
And finally, a lot of people ended up writing their own frameworks and the like, because they could. But also because there weren't any or not many good and widely adopted frameworks out there, that came later with first Zend Framework and then Laravel, the latter being the de-facto standard nowadays.
It's like walking on minefields with very different "mine densities"; when using something stricter, you would have one mine per acre, with PHP you would have ten.
For the longest time the language had been developed with this mentality that it's okay to continue running if something broke, that it's better to print out something than to do nothing and bail out.
Which means that for things to run reliably, you have to write very defensive code that checks everything you can think of. Which is probably a good idea with any language, but I find that old PHP requires much more of this.
Thankfully, they've been changing that over the past decade while still maintaining decent compatibility with old code. I just recently finished porting a pretty large project (~2 mil SLoC) from the ten year old 5.6 to the currently latest 8.4, and it's been pretty painless. The only things that broke were those that were never actually properly implemented and worked by pure chance.
Give me an example where PHP invites developers to do terrible things and I'll show you 2 other popular languages that invite equally bad or worse things :)
Or as Bjarne Stroustrup put it: There's two types of languages: The ones people complain about and the ones noone uses
The @ operator of php. In languages like Java, to silently catch all exceptions and do nothing with them requires at least some boiler plate.
PHP has an operator for something you should never do in a sane codebase.
You know that python wants good good to look good?
PHP was written in a way that makes bad code look good. And if we want Software Engineering to be a serious field that evolves, we have to be able to be honest with ourselves. It is a bad tool. Good programmers can even write good programs with bad tools. Doesn't mean you shouldn't avoid bad tools given the option.
There probably is a "PHP the good parts". But Javascript actually had a pretty nice core, and an utility of being in all web browsers that no other language could replicate. What niche does PHP have where it brings more value there other nicer languages can't be used instead?
> The @ operator of php. In languages like Java, to silently catch all exceptions and do nothing with them requires at least some boiler plate.
The @ operator doesn't get rid of exceptions it get rids of "warnings" which are basically built in log messages.
It used to get a bad wrap for also silencing fatal errors, but it stopped doing that a while ago.
The @ operator is something that should only be rarely used, but it is no way comparable to catching exceptions and doing nothing with them. There are sane uses for it.
You absolutely can use @ in sane codebases. And you give the example yourself: In other languages you often enough see that boilerplate where thrown exception is discarded, because there is no sane reaction to some edge case and you just want the program to continue, because you know it will work anyway. And that's @.
Note though that @ was already neutered in some earlier recent PHP releases.
One common use case for the @ operator, is when "destructuring" array members into variables. In some cases, you can't know if the member will be available, but it's not important if it's missing. In that case, you can silence the warning.
The claim was "PHP invites bad code" - but your point is for "bad code can be written in PHP" which is really not the same thing. A quick google for the @ brought up https://stackoverflow.com/questions/136899/suppress-error-wi... where the highest voted response is ~"NO, don't use it please".
No use case I've come across during the past 10 years has required or even nudged me in the direction of @. It's an ancient relic that the whole community considers a no-no. I'd be curious if you really want to argue that this state of affairs "invites" using the @.
You can do crazy things in every language. However, in a language like Java, the crazy things are more conceptual (factory for factory of factories) and not basic things like what does == mean or problems with weak typing and implicit conversions. A lot of the issues with PHP can be avoided in modern PHP using things like strict_types=1, but most of the time, we don't get to work with projects using best practices. And I'd rather work with a bad Java project than any bad PHP project (which I have had the misfortune of maintaining).
Funny that you picked == as an example when == is very counter intuitive in Java and is one of the common pitfalls for beginners:
String a = new String();
String b = new String();
a = "test";
b = a + "";
if (a == "test")
{
// true
}
if (b == "test")
{
// false
}
if (a == b)
{
// false
}
Just like PHP, you have to read the docs to use it properly.
This is a decade-old PHP defence fallacy. No one says other languages have no problems, so "disproving" that is the fallacy. PHP just has far more problems and footguns. Maybe now it has fewer, but still. Far more.
So you're going to ignore the rest of what I wrote? I'll just assume you agree with me and the rest of my comment, but you don't want to admit it. Works for me.
I'd take PHP instead of JS/TS + framework-of-the-day on the backend anytime. Ok, PHP is usually also paired with a framework (cough Laravel cough), but at least there the situation is more stable, not to mention more mature. Unfortunately, I'm not the only one making the decisions...
PHP has introduced breaking changes, deprecations etc. in a somewhat rapid fashion.
PHP doesn't prioritize stability, but language features and cleanup. It's an impressive technical endeavor that has its merits, but comes with a tradeoff.
Within the last 10 years, the language itself broke twice. And that's not counting the ecosystem on top of it. Common frameworks, libraries etc. tend to break relatively often as well.
There are languages that are _much_ more stable and reliable than that.
A lot of C# and Java code is oriented towards web backends, too. Which are quite big and complex. So it seems natural that languages in the same design space (trad OO) converge on similar features. I think the only exception these days is Go.
I think these days you could change "You can write Fortran in any language" to "You can structure your code like Spring in any language"…
Still, even if it was "just" the web, why wouldn't it evolve? It's a great language, with a big user base, and there's always room for improvements and to increase the developer experience
I don't see how making a language more complex can help with that. Complex languages makes sense for system programming where you want to squeeze some performance.
I downvoted you before reading the fine article. I'm back to correct that.
The new array_first() and array_last() functions are nice, everything else is either reimplantation of existing features or "features"which will make maintainability more difficult. The pipe operator is one such example. I don't need it - these nested methods are not really an issue in any codebase I've seen. The new syntax only works for unary functions, so higher arity functions must be wrapped in an arrow function. It's a mess and more bug prone than just nesting the functions.
Many of the newer features have this problem. Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features.
Meanwhile it seemingly abandoned features and unique selling points, like the in-built templating, associative arrays with value semantics and the fact that it integrates well with C or the simple fact that it can be used to write web server scripts very easily. To me, many of these cool features have been largely ignored or even moved away from.
PHP should REALLY focus on getting the core stuff in shape.
Its still so annoying that you have to use mb_real_uppercase($name) for unicode. The other gripe is that the stdlib is SO messy. With PHP 5.3 they had a once in a lifetime opportunity to cleanup the stdlib and introduce a new namespaced API for builtins, and optionally introduce a uniform function call syntax:
"foo"->strtoupper();
Whenever doing PHP the time for concurrency will come sooner or later. Having no way of doing ANY concurrency is a letdown. The Fiber API does nothing on its own, and you are forced to use some third party runtime, that is usually a non-starter for legacy projects.
PHP has come a long way from the PHP 4.0 era, but is still lacking in multiple areas, and i dont see it being a pick for greenfield projects in 2025.
As for concurrency/async, it's possible to do requests in parallel with curl_multi_*. Other async/prallel things are also possible, but tend to be more complicated compared to JS or other languages with promise and async support.
That is an anti-pattern, since it suffers from shell meta-character injection (and argument injection). Since PHP has mkdir, you should use that instead. And pcntl_exec() is the correct API for running processes.
Typical users of this likely don't care the slightest about whether anyone considers it an anti-pattern, because you use those in order to write utility scripts. And those who care would use tooling to detect issues like that anyways.
Why is it that all these languages like PHP, but also typescript are becoming like impossible puzzles to read. I find these generics, types and other language features very often causing complex software architecture. I see so many collegues these days struggling in understanding codebases. You almost need a PHD brain to be a frontend web developer.
I assume it is some inferiority complex, on many sides. PHP itself was laughed at being too simple, underpowered and inconsistent, now they overcorrected with types, annotations and breaking backwards compatibility with every release so that no old code base can remain intact. Frontend devs yearned to be regarded as real developers, which in their context means construction of unwieldly and overcomplex enterprise bullshit, thus typescript etc. And in the backend you have that same mechanism, devs having to prove they are no beginners and thus using (wrongly) design patterns, instructed by software architects, instead of avoiding abstraction and thus complexity.
I remember the discussions at the time about which filename extension to use - and I can not believe that .php3 won. I think that I was the first to bring up the subject for PHP 4, to use .php again and not include the version number.
What do you mean developers should deal with functions like those? They're used when necessary, yes, just like any function. And no IDE is required. I'm really puzzled.
It seems that pipe operator was introduced largely because PHP arrays and strings don't have "methods". You can't write something in "OOP" style: "some_string"->str_replace("some", "replacement")->strtoupper(). With PHPs array / string procedural way writing such chains is much bulkier. Pipe operator will somewhat reduce the boilerplate, but the native "OOP" style is still much better.
Although there is a proposal for adding "methods" but I don't remember the link.
I'm not a blind PHP hater, but it seems like PHP community members sometimes celebrate new PHP features when their equivalents have been there for many years in other programming languages. https://waspdev.com/articles/2025-06-12/my-honest-opinion-ab...
No, the OOP style isn't better. The set of functions one can use in OOP is closed.
Imagine I want to AfD a custom string function for a feature which uPpErCaSeS every second letter as I need that for some purpose: I can't do in OOP style.
In OOP I could extend the string class, but most other parts of the code won't magically use my string type now.
Thus I have to create a free standing function for this (which probably also is better as I don't need internal state of thee object, thus livingnoutisde is good for encapsulation)
And thus my string function works different from other string functions.
my_casing($string->trim())->substr(3);
(The example of course is non sensical and could be reordered, but we argue syntax)
Having them all be simple functions makes it equal.
Of course there are alternative approaches. C++ argues for years about "uniform call syntax" which would always allow "object style" function calls, which could also find non-memwbr functions where the first argument is of compatible type, but such a thing requires stricter (or even static) typing, this won't work in PHP.
Such a change makes it a completely different language with no compatibility. Thus all previous code is lost, no easy migration paths (especially for libraries which would like to support both during transition)
PHP's evolution since PHP 5 has been substantial, and I think this is a real problem. As someone who learned the language years ago, the pace of change (generics, attributes, match expressions, typed properties) makes modern codebases genuinely difficult to follow.
I suspect this affects many developers who cut their teeth on PHP but haven't kept up. The language has become a different beast, which is a strength for the community but a barrier to re-entry.
IMO, newer PHP is still very readable. I programmed with C++ for a decade, but I can safely say that I cannot understand a modern C++ code base anymore.
I think PHP is way better now than it used to be. Learn PHP 8 and you are good to go.
This is true for most languages though, compare C# 14 with C# 1.0, Java 25 with Java 1.0, C 23 (plus common compiler extensions) with K&R C,....
C hasn’t changed all that much, and someone who coded in C99 would take about 30mins to catch up to a modern C23 codebase’s changes. Famously so, as conservatism to change is the main friction in the community for about two decades now.
If you pull out examples of the earliest C, sure, it looks weird. But that C was already obsolete in 1989. Since then, it’s had a minor iteration (e.g. five-eight additions/modifications) every decade-ish (99, 11, 17, 23). Has it changed? Sure. Can it be compared to the iteration and speed of things like C#, Java, C++, etc? No way.
I am quite sure many people would fail Pub Quizzes related to C, when taking into account the whole language alongside compiler extensions, regardless of the compiler.
To learn all of the common GCC and MSVC extensions would make up a fraction of the language features of C# or Java. You’re really overstating the complexity to make some invalid point.
“Actually, one of the most notoriously conservative and simple (in feature set) languages is really super complex and has evolved a ton because it has _Generic and varargs now, and __packed__ exists as a compiler feature.”
And to further double down, that minor evolution is over 36 years (arguably a decade longer, but I’m being generous with your argument). Not the 12-16 years (depending which 5 point release you wanna start with) that PHP has morphed into an entirely different language.
I think he's thinking more along the lines of PHP 5-8.5
That version 1-latest is understandingly highly different, but these are all decades old languages, which barely changed for some time, but are now all introducing new syntax.
Which I think makes sense, but it's obviously going to leave 9-5 devs behind that don't particularly care for coding and want to invest as little time as possible into their language knowledge.
And what exactly 9-5 has to do with caring for coding or time investment in language learning?
Most likely this can be said about a lot of languages, most languages are being maintained and improved. I am an hired expert in Java and I needed to explain some new languages features to some colleagues that have been introduced recently, I only mention them if they actually improve readability though. I think PHP might be slightly different than other languages as a huge amount of people use this to create their first website as a hobby.
PHP has no generics? I read somewhere that is was "too hard" to get right in PHP land, mostly because of how primitive the typesystem is.
It has nothing to do with being “too hard”, and everything to do with not making sense to the type system. PHP is weakly-typed and heavily reflection-based (so everything is aware of it’s and each other’s type at all times).
Adding generics to PHP would make CS fundamentalists somewhat happy, but do nothing to change the fundamental design of PHP nor offer any of the traditional benefits that generics offer to strongly-typed and compiled languages. And would be a massive headache to implement, while bulking an already heavy VM implementation.
> And would be a massive headache to implement
Exactly. The type system was never built for anything even slightly more complex. Its basically annotations for primitive types and classes. PHP has always had an weak type system, so adding generics will most likely never happen.
> Adding generics to PHP would make CS fundamentalists somewhat happy
PHP has really only one collection datatype (the infamous array), so having generics would be tremendously useful, as an example you cant return an typed array from a function, witch is just really bad.
For an counter example, Python managed to do this, while also being a dynamic language, although having a stronger typing than PHP.
If you're interested about generics in PHP, you can read this blog post by the PHP foundation: https://thephp.foundation/blog/2024/08/19/state-of-generics-... or this PR by Nikita: https://github.com/PHPGenerics/php-generics-rfc/issues/45.
TLDR: The PHP compiler isn't really suited for the job, it would introduce a lot of complexity to an already complex codebase and the memory/performance hit would be substantial.
Yup, this was pretty much what i recalled. The typesystem, while being incredibly "unintelligent", somehow still is so complex that generics are not going to happen.
I still love PHP. 23 years ago we created some encryption software for it and it is still going. I also run a PHP newsletter. There's still a strong community of people and whilst there are other languages which I also use (Python, Node.js) I still find myself gravitating towards PHP for fast and simple work
The only issues I have. is that this is a 'double edged sword' in that PHP has become far more complex since the launch of PHP 5 and so it isn't as easy to understand from scratch as it used to be
> 23 years ago we created some encryption software for it
ZEND?
I remember "nulling" software in the mid-00's and Zend was always a terrible ball-ache.
Which, if that was your project, is high praise. :)
Can’t believe we’re getting array_first, array_last and fatal error stack traces in PHP before GTA6.
Nice additions, but haven't really missed them a lot.
Most of the time if I want the first or last element I don't care about the array itself so array_shift and array_pop work just fine.
A lot of people are too proud to be associated with PHP. I am ready to admit that know nothing about the language except that a lot of people make cool things with it.
My favourite PHP product at the moment is BookStack (https://www.bookstackapp.com/), a really good wiki. I run an instance for my family and it's great.
But there are loads of things. And I notice that many of the sites I like using...are built on well maintained PHP stacks.
PHP is a very pleasant and straight-forward language to work with. I enjoyed my time working with it, though I did also see quite a lot of very poor code.
I think the danger with PHP is more its ability to easily cause *very bad things*.
This would partially be poor training (my University literally taught PHP with SQL-injectable examples), and I think the language itself making it very easy, such that less-experienced developers using it - most of them, early on - don't realise what's wrong until it's gone wrong.
With PHP being such an early tool online, and the above properties existing, it earned a reputation for being insecure and bad.
At least in my experience, the early years of PHP was lacking more enterprisey users; back then there was a small revolution when RoR came out and introduced the MVC pattern to a lot of (web) developers, who didn't have as opinionated a pattern / architecture up until then.
During that same period, there were a lot of mediocre tutorials and documentation online, including on the PHP website itself which allowed people in comments to post code examples, but as far as I know there wasn't a lot of moderation on those.
And finally, a lot of people ended up writing their own frameworks and the like, because they could. But also because there weren't any or not many good and widely adopted frameworks out there, that came later with first Zend Framework and then Laravel, the latter being the de-facto standard nowadays.
> I think the danger with PHP is more its ability to easily cause very bad things.
Is there any language where you can't?
It's like walking on minefields with very different "mine densities"; when using something stricter, you would have one mine per acre, with PHP you would have ten.
For the longest time the language had been developed with this mentality that it's okay to continue running if something broke, that it's better to print out something than to do nothing and bail out.
Which means that for things to run reliably, you have to write very defensive code that checks everything you can think of. Which is probably a good idea with any language, but I find that old PHP requires much more of this.
Thankfully, they've been changing that over the past decade while still maintaining decent compatibility with old code. I just recently finished porting a pretty large project (~2 mil SLoC) from the ten year old 5.6 to the currently latest 8.4, and it's been pretty painless. The only things that broke were those that were never actually properly implemented and worked by pure chance.
Probably not, but not most languages are not inviting to do them.
Give me an example where PHP invites developers to do terrible things and I'll show you 2 other popular languages that invite equally bad or worse things :)
Or as Bjarne Stroustrup put it: There's two types of languages: The ones people complain about and the ones noone uses
The @ operator of php. In languages like Java, to silently catch all exceptions and do nothing with them requires at least some boiler plate.
PHP has an operator for something you should never do in a sane codebase.
You know that python wants good good to look good?
PHP was written in a way that makes bad code look good. And if we want Software Engineering to be a serious field that evolves, we have to be able to be honest with ourselves. It is a bad tool. Good programmers can even write good programs with bad tools. Doesn't mean you shouldn't avoid bad tools given the option.
There probably is a "PHP the good parts". But Javascript actually had a pretty nice core, and an utility of being in all web browsers that no other language could replicate. What niche does PHP have where it brings more value there other nicer languages can't be used instead?
> The @ operator of php. In languages like Java, to silently catch all exceptions and do nothing with them requires at least some boiler plate.
The @ operator doesn't get rid of exceptions it get rids of "warnings" which are basically built in log messages.
It used to get a bad wrap for also silencing fatal errors, but it stopped doing that a while ago.
The @ operator is something that should only be rarely used, but it is no way comparable to catching exceptions and doing nothing with them. There are sane uses for it.
You absolutely can use @ in sane codebases. And you give the example yourself: In other languages you often enough see that boilerplate where thrown exception is discarded, because there is no sane reaction to some edge case and you just want the program to continue, because you know it will work anyway. And that's @.
Note though that @ was already neutered in some earlier recent PHP releases.
This.
One common use case for the @ operator, is when "destructuring" array members into variables. In some cases, you can't know if the member will be available, but it's not important if it's missing. In that case, you can silence the warning.
$array = ['apple', 'pear']; @list($mainFruit, $secondaryFruit, $tertiaryFruit);
Since I suppress the warning that would occur due to the third member not being present, the program will continue executing instead of halting.
The claim was "PHP invites bad code" - but your point is for "bad code can be written in PHP" which is really not the same thing. A quick google for the @ brought up https://stackoverflow.com/questions/136899/suppress-error-wi... where the highest voted response is ~"NO, don't use it please". No use case I've come across during the past 10 years has required or even nudged me in the direction of @. It's an ancient relic that the whole community considers a no-no. I'd be curious if you really want to argue that this state of affairs "invites" using the @.
You can do crazy things in every language. However, in a language like Java, the crazy things are more conceptual (factory for factory of factories) and not basic things like what does == mean or problems with weak typing and implicit conversions. A lot of the issues with PHP can be avoided in modern PHP using things like strict_types=1, but most of the time, we don't get to work with projects using best practices. And I'd rather work with a bad Java project than any bad PHP project (which I have had the misfortune of maintaining).
Funny that you picked == as an example when == is very counter intuitive in Java and is one of the common pitfalls for beginners:
Just like PHP, you have to read the docs to use it properly.This is a decade-old PHP defence fallacy. No one says other languages have no problems, so "disproving" that is the fallacy. PHP just has far more problems and footguns. Maybe now it has fewer, but still. Far more.
So you're going to ignore the rest of what I wrote? I'll just assume you agree with me and the rest of my comment, but you don't want to admit it. Works for me.
I’ve made my living amd career off of PHP and I enjoy its modernization.
Coding in PHP can be a lot like playing the guitar or writing poetry: many people can do it, but it’s easy to do very badly.
I'd take PHP instead of JS/TS + framework-of-the-day on the backend anytime. Ok, PHP is usually also paired with a framework (cough Laravel cough), but at least there the situation is more stable, not to mention more mature. Unfortunately, I'm not the only one making the decisions...
PHP is a reasonable choice if you care about writing something that will still work out of the box 10 years from now.
But of course this assumes that you work with a team that can see a year ahead, let alone 10.
PHP has introduced breaking changes, deprecations etc. in a somewhat rapid fashion.
PHP doesn't prioritize stability, but language features and cleanup. It's an impressive technical endeavor that has its merits, but comes with a tradeoff.
Within the last 10 years, the language itself broke twice. And that's not counting the ecosystem on top of it. Common frameworks, libraries etc. tend to break relatively often as well.
There are languages that are _much_ more stable and reliable than that.
https://github.com/AzuraCast/AzuraCast
AzuraCast because I like learning by looking at code and hosting my own radio/music
> My favourite PHP product at the moment is BookStack (https://www.bookstackapp.com/), a really good wiki.
Another wiki that uses php is Wikipedia.
People like to shit on php but it powers some of the largest sites in the world.
At the end of the day, programming language doesn't matter much. You can be a good programmer in any language and a bad programmer in any language.
> A lot of people are too proud to be associated with PHP.
How so?
Vanity, it's "PersonalHomePage" language
PHP becomes a complex language with each update. For what reason? Its application is still limited to the web, mostly.
A lot of C# and Java code is oriented towards web backends, too. Which are quite big and complex. So it seems natural that languages in the same design space (trad OO) converge on similar features. I think the only exception these days is Go.
I think these days you could change "You can write Fortran in any language" to "You can structure your code like Spring in any language"…
Obviously you haven't heard of NativePhp :)
Still, even if it was "just" the web, why wouldn't it evolve? It's a great language, with a big user base, and there's always room for improvements and to increase the developer experience
The web is not getting any simpler.
I don't see how making a language more complex can help with that. Complex languages makes sense for system programming where you want to squeeze some performance.
Exactly, I'd even argue that web development (back & front-end) is by far the largest job / industry in software development.
I downvoted you before reading the fine article. I'm back to correct that.
The new array_first() and array_last() functions are nice, everything else is either reimplantation of existing features or "features"which will make maintainability more difficult. The pipe operator is one such example. I don't need it - these nested methods are not really an issue in any codebase I've seen. The new syntax only works for unary functions, so higher arity functions must be wrapped in an arrow function. It's a mess and more bug prone than just nesting the functions.
Many of the newer features have this problem. Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features.
Meanwhile it seemingly abandoned features and unique selling points, like the in-built templating, associative arrays with value semantics and the fact that it integrates well with C or the simple fact that it can be used to write web server scripts very easily. To me, many of these cool features have been largely ignored or even moved away from.
The pipe operator makes it much easier to create home-grown cryptographic hash functions, as everybody used to do in the early 2000s:
Oh, now I'm convinced!
> The pipe operator [...] syntax only works for unary functions, so higher arity functions must be wrapped in an arrow function.
It's coming - but to get PHP RFCs to pass they have to be salami-sliced, otherwise they're voted down.
https://wiki.php.net/rfc/partial_function_application_v2
Official release notes: https://www.php.net/releases/8.5/en.php
PHP should REALLY focus on getting the core stuff in shape.
Its still so annoying that you have to use mb_real_uppercase($name) for unicode. The other gripe is that the stdlib is SO messy. With PHP 5.3 they had a once in a lifetime opportunity to cleanup the stdlib and introduce a new namespaced API for builtins, and optionally introduce a uniform function call syntax:
Whenever doing PHP the time for concurrency will come sooner or later. Having no way of doing ANY concurrency is a letdown. The Fiber API does nothing on its own, and you are forced to use some third party runtime, that is usually a non-starter for legacy projects.PHP has come a long way from the PHP 4.0 era, but is still lacking in multiple areas, and i dont see it being a pick for greenfield projects in 2025.
Yeah, the core ergonomics is significantly lagging behind most other backend languages despite improvements in some areas. I even wrote an article https://waspdev.com/articles/2025-06-12/my-honest-opinion-ab... .
As for concurrency/async, it's possible to do requests in parallel with curl_multi_*. Other async/prallel things are also possible, but tend to be more complicated compared to JS or other languages with promise and async support.
The most exciting thing about the PHP8.5 announcement is the stability and maturity of PHP
like in `mkdir $dirname`;
That is an anti-pattern, since it suffers from shell meta-character injection (and argument injection). Since PHP has mkdir, you should use that instead. And pcntl_exec() is the correct API for running processes.
Typical users of this likely don't care the slightest about whether anyone considers it an anti-pattern, because you use those in order to write utility scripts. And those who care would use tooling to detect issues like that anyways.
When I look at the new pipe syntax ...
... I think why not just something like the following?The three dots in trim(...) make a callable out of a function, that was already in, so seem best to re-use that syntax, at least for now. [1]
As for the partial function application, there is already an RFC to add that, but it's not decided on as of now. [2]
1: https://www.php.net/manual/en/functions.first_class_callable...
2: https://wiki.php.net/rfc/partial_function_application_v2
PHP has really come a long way since I used it in the 90s on my first little website.
Looking forward for true async to land - nothing here gets me too excited.
Why is it that all these languages like PHP, but also typescript are becoming like impossible puzzles to read. I find these generics, types and other language features very often causing complex software architecture. I see so many collegues these days struggling in understanding codebases. You almost need a PHD brain to be a frontend web developer.
Like on of my sibling comment, I truly believe this is connected to some degree of social pressure.
People pointing fingers to "outdated" languages for not having some of the most trendy constructs.
The pipe operator is definitely one of the feature that create more ways to do the same thing while providing unclear benefit.
Never in my life I was in a situation like "with the pipe operator this I would have saved me hours of debugging/reading/creating code".
I assume it is some inferiority complex, on many sides. PHP itself was laughed at being too simple, underpowered and inconsistent, now they overcorrected with types, annotations and breaking backwards compatibility with every release so that no old code base can remain intact. Frontend devs yearned to be regarded as real developers, which in their context means construction of unwieldly and overcomplex enterprise bullshit, thus typescript etc. And in the backend you have that same mechanism, devs having to prove they are no beginners and thus using (wrongly) design patterns, instructed by software architects, instead of avoiding abstraction and thus complexity.
No, I'm not bitter.
It's somewhat comforting to read my insecurities shared by others in this thread
Thanks PHP for bringing pipe operator in 2025.
still remember been on #php with count down to php3 announcement
I remember the discussions at the time about which filename extension to use - and I can not believe that .php3 won. I think that I was the first to bring up the subject for PHP 4, to use .php again and not include the version number.
in 2025 developers who are programming in PHP should still deal with str_replace, htmlspecialchars, nl2br (the list goes on and on).
(no, I don't want my IDE to babysit me, and ideally I don't want to use IDE at all)
What do you mean developers should deal with functions like those? They're used when necessary, yes, just like any function. And no IDE is required. I'm really puzzled.
> And no IDE is required.
What else to say, good luck.
You didn't get the anecdote, that's probably because you haven't worked with PHP (long enough).
I will give hint: inconsistency.
tl;dr: nothing interesting, just stability and maturity
And a pipe operator, which is also being discussed in a number of other languages.
It seems that pipe operator was introduced largely because PHP arrays and strings don't have "methods". You can't write something in "OOP" style: "some_string"->str_replace("some", "replacement")->strtoupper(). With PHPs array / string procedural way writing such chains is much bulkier. Pipe operator will somewhat reduce the boilerplate, but the native "OOP" style is still much better.
Although there is a proposal for adding "methods" but I don't remember the link.
I'm not a blind PHP hater, but it seems like PHP community members sometimes celebrate new PHP features when their equivalents have been there for many years in other programming languages. https://waspdev.com/articles/2025-06-12/my-honest-opinion-ab...
No, the OOP style isn't better. The set of functions one can use in OOP is closed.
Imagine I want to AfD a custom string function for a feature which uPpErCaSeS every second letter as I need that for some purpose: I can't do in OOP style.
In OOP I could extend the string class, but most other parts of the code won't magically use my string type now.
Thus I have to create a free standing function for this (which probably also is better as I don't need internal state of thee object, thus livingnoutisde is good for encapsulation)
And thus my string function works different from other string functions.
(The example of course is non sensical and could be reordered, but we argue syntax)Having them all be simple functions makes it equal.
Of course there are alternative approaches. C++ argues for years about "uniform call syntax" which would always allow "object style" function calls, which could also find non-memwbr functions where the first argument is of compatible type, but such a thing requires stricter (or even static) typing, this won't work in PHP.
PHP should do a real major compatibility break and remove $ sigil from variable names. It's gonna be worth the pain!
Hello Perl 6!
Such a change makes it a completely different language with no compatibility. Thus all previous code is lost, no easy migration paths (especially for libraries which would like to support both during transition)