PHP 8.4.4 Released
php.net
php.net
https://www.php.net/ChangeLog-8.php#8.4.4
That being said, this is a pretty boring release. Save the upvotes for 8.5 when it comes? :)
Source: a PHP developer ;P
But I agree, a minor release is hardly news worthy
As a PHP developer myself, I'm still not clear as to why that warrants a submission to HN, much less a promotion to the front page.
If you care about performance in Webapps while using dynamic languages, it is pretty much PHP or nodejs, at least until CPython and Ruby MRI JITs improve.
I would have added VB.NET, but it isn't going anywhere nowadays.
Take Go as an alternative. Has unicode etc but still lots faster than PHP.
Also PHP is far from slow. The code is precompiled ("cached") and the common operations are optimized as hell. IME the slow apps are usually just missing some MySQL indexes or similar.
This is pure CPU bound (the IO is only opening a file and not a bottleneck) and PHP is still very slow for anything more complex.
I haven't try things like FrankenPhp though.
2. You are could replace every instance of "php"!in that text with "Javascript" and it would be about equally true: some things more, some things less, but in general they are equally bad. Doesn't prevent people from making great things with both.
Especially if you use strict mode, PhpStan etc.
There's still some surprising behavior sometimes, like how array_merge handles non-int keys but it's all in the documentation.
PHP still has its warts -- like any language -- but with IDEs (which weren't around in 2012) and modern frameworks, you don't run into them very often.
Relevant in what way? Relevant as in they are factual or relevant to the day to day of a real PHP developer, because I can tell you the latter didn't hold up even when this was written.
> even a decade has passed
We got more optional typing and better error handling, and I'm still able to run the awful code I have written a decade ago.
Java is an almost 30 year old language and I can still do this:
String foo = null; System.out.println("hello" + foo.length());
> Make you wonder what the hell php devs are really doing?
Incrementally improving the language without breaking too much.
> 60% true still. Most of the issues are in "wontfix" mode.
Most of those are quirks that you can safely ignore, and "fixing" them would result in breaking a lot of the existing code, which is not worth it.
So is Python's yet the language is enjoying great success.
> All the builtin functions still have no namespaces, and no forced types.
And no PHP developer cares, because neither does C and yet it's doing just fine.
> PHP still coerces strings to ints and vice versa.
Which is great for beginners, because they don't need to worry about it, unlike me when I program in Rust and have to deal with 8+ number types.
> PHP still has serious bugs with its (only) collection, the frankenstein ARRAY.
So does JavaScript, yet it's not enough to stop the language.
> IIRC doing a array_filter is still broken on PHP8 for key val arrays.
There is some odd behavior if you try to do certain things in a functional style that is actually true.
> PHP still had no unicode in 2023, im not sure how the latest version fixed this or not. IIRC you had to use the weird mb_real functions to get anything closely functional, and it was a mess.
That can get annoying in some use cases, I have developed many international web apps in PHP, it rarely got in my way, but I do acknowledge that it's not great to not have Unicode by default, I suspect they are afraid to resolve this after seeing what happened with Python 3.
Still gets dunked on, still powers a big chunk of the web.
IF this is the measure, why not count PHP as C, as its written in C?
I stil argue that a single javascript library (jQuery) is MORE popular in 2025 than all PHP installations combined. Take that for scale. Now add all javascript (non compiled) and it trumps PHP by a factor of 100.
> PHP is inconsistent: strpos, str_rot13
I used PHP for two decades and the naming issues while being annoying didn't really bother me in real life, nobody would tell you not to use C because you have 10 bad implementations of the same string method with weird names.
> Side observation: I loooove Python. I will also happily talk your ear off complaining about it, if you really want me to. I don’t claim it’s perfect; I’ve just weighed its benefits against its problems and concluded it’s the best fit for things I want to do.
You should check out the moment you reach this paragraph because Python has similar and sometimes worse developer experience issues.
> There’s no clear design philosophy. Early PHP was inspired by Perl; the huge stdlib with “out” params is from C; the OO parts are designed like C++ and Java.
Exactly, the language has a lot of old cruft, just like most old languages, but that does not matter, what matters is how well you can use it to build something useful today.
> There is no threading support whatsoever.
Neither in JavaScript and nobody developing JavaScript is missing horrors of threads, if you need that level of performance, there are more suitable languages out there.
> In PHP, these functions return false. If you use FALSE as an index, or do much of anything with it except compare with ===, PHP will silently convert it to 0 for you.
Just like in JavaScript, yet people are still able to build big things.
> There is no way to declare a variable. Variables that don’t exist are created with a null value when first used.
This is coming from someone who loves Python.
> PHP is dynamically-typed, so variables generally have no type… except references, which adorn function definitions, variable syntax, and assignment.
Not true anymore.
> Constructs
Full of nitpicks and statements that are wrong or don't mean anything.
> echo is a statement-y kind of thing, not a function.
This is a problem because?
> There’s redundant syntax for blocks: if (...): ... endif;, etc.
Because it used to be a templating language, don't use it or do use it, nobody will care either way.
> Error handling
It's configurable and you can configure it to meet your needs, moving on.
> PHP errors and PHP exceptions are completely different beasts. They don’t seem to interact at all.
They do now.
> But you can’t require that an argument be an int or string or object or other “core” type, even though every builtin function uses this kind of typing, probably because int is not a thing in PHP.
You can now.
> The procedural parts of PHP are designed like C, but the objectional (ho ho) parts are designed like Java. I cannot overemphasize how jarring this is.
It's not, you read the docs, you get the job done.
> clone is an operator?!
What does it matter if it's an operator or a function that is in the standard library?
> There is no module system.
There is Composer and you get an experience similar to Java.
> There are thousands of functions in the global namespace.
And this will destroy my productivity because?
> PHP basically runs as CGI. Every time a page is hit, PHP recompiles the whole thing before executing it. Even dev servers for Python toy frameworks don’t act like this.
Person writing this is not very experienced, because this hasn't been the norm for a long time.
> PHP is naturally tied to Apache. Running it separately, or with any other webserver, requires just as much mucking around (possibly more) as deploying any other language.
Author doesn't know what they are talking about, you can use whatever webserver you want.
> Similarly, there is no easy way to “insulate” a PHP application and its dependencies from the rest of a system. Running two applications that require different versions of a library, or even PHP itself? Start by building a second copy of Apache.
This is coming from someone who likes Python which has the same problem.
> The “bunch of files” approach, besides making routing a huge pain in the ass, also means you have to carefully whitelist or blacklist what stuff is actually available, because your URL hierarchy is also your entire code tree. Configuration files and other “partials” need C-like guards to prevent them from being loaded directly. Version control noise (e.g., .svn) needs protecting. With mod_php, everything on your filesystem is a potential entry point; with an app server, there’s only one entry point, and only the URL controls whether it’s invoked.
You use a framework and all of these problems go away.
> You can’t seamlessly upgrade a bunch of files that run CGI-style, unless you want crashes and undefined behavior as users hit your site halfway through the upgrade.
Has this person heard about containers or symlinks?
> No template system. There’s PHP itself, but nothing that acts as a big interpolator rather than a program.
Twig, Smarty etc.
> No XSS filter. No, “remember to use htmlspecialchars” is not an XSS filter. This is.
Use a framework.
> No CSRF protection. You get to do it yourself.
That's what frameworks do in any language.
> No generic standard database API. Stuff like PDO has to wrap every individual database’s API to abstract the differences away.
PDO is the standard database API.
-------
As someone who actually used PHP to get real work done I find this article very nitpicky and get the impression that it's mainly taking potshots rather than looking at things that actually matter day to day.
Majority of what is in this article doesn't matter in real life, a lot of the things that do matter have been fixed, there are some legitimate points that do impact you and have not been fixed yet, but they are few and far between.
This article compares core PHP with a framework from some other language, which is unproductive because most of the time you should be using a framework but at the same time it's impressive that you can actually write real applications just by using the standard library, I would not recommend it though.
PHP is incredibly stable, scales horizontally by default and has amazing documentation. I have applications I have built 13+ years ago and I can still get them to work with minimal effort on the latest PHP. PHP has a very low barrier of entry which can be incredibly helpful.
Is PHP without flaws? Of course not, some of the syntax is quirky and it's full of legacy code.
I always recommend: pick the framework not the language, if the way the framework works suits you, then choose it, otherwise find another one that is better suited to your exact needs, if I were to have a beginner write something, a PHP-based framework would be a good entry point, because they can learn the basics without worrying about typing too much.
> Person writing this is not very experienced, because this hasn't been the norm for a long time.
I’m genuinely curious—what is the norm here now? I see a lot of PHP code, and 90% of it is just setting up the environment from the ground up, while only 10% is the real processing. The good side is being stateless, but the performance penalty is enormous. I still see a lot of file caching (please make this dir 777 for production) to mitigate some of it, but Redis has become remarkably visible over the last years.
Not being a PHP expert, I really need some best practices to point devs to.
Either way you are not going to pay for the PHP process startup cost.
PHP can also cache the interpretations of files so you avoid that cost as well.
And frameworks usually have their own usually file-based caching mechanism.
At the end of the day it's still going to have some costs compared to a single application server model, but for most web apps it's not going to matter, however it greatly simplifies the programming model.
But it’s not the language itself, as I was advised. True asynchronous handlers are possible, which is promising.
It doesn't need to go far, because it's selling point is that it's easy to learn and use.
The way I see PHP is not as a competitor to Java, .Net, NodeJS or Rust, instead I see it as a platform for non-advanced developers to be able to be able to create things and actually have the whole thing be cheap and sustainable.
> But it’s not the language itself, as I was advised. True asynchronous handlers are possible, which is promising.
The whole point of PHP is that it's single threaded, blocking and from the developer's point of view: your program starts at the request and terminates when the HTTP request is complete, this is what makes it simple to comprehend, if you want async, I would tell you to use something like Node instead.
> File caching is evil—many PHP devs love using the filesystem to store things, which is pretty nasty under K8s.
It's usually just an annoyance or just something you need to configure or just brute force it with a shared mount.
> I’ve seen a lot of WordPress plugins with spaghetti code being called on every invoked endpoint.
That's not really the problem of the language itself, the language doesn't force you to run anything on every request.
I made a PHP CAPTCHA that requires no JavaScript, so pretty much everything?
What would a client-side language have to do with CAPTCHA? Kind of defeats the purpose of it, or rather, what it (server-side) does not have to do with it?
Have you tried building web apps at all in these languages as opposed to PHP?
I do not like PHP much but I don't get the hatred. I chose PHP as opposed to Go (and I never, ever considered a JVM-like language) when trying to make a simple CAPTCHA, but I did choose PHP for a full-blown e-commerce website too.
PHP has built-in session handling, the deployment is extremely simple and works out of the box, and PHP's server-side rendering aligns perfectly well with no-JavaScript sites, form handling and image submission work natively with PHP, and so on. Go may offer better raw performance but it does not make sense to use Go, and it is laughable to ever consider Java or Kotlin for it.
If you need an exhaustive list as to why picking PHP is the right (or pragmatic) choice here as opposed to Go or JVM-like languages, let me know and I will provide you one.
How about just write the code, using the stdlib and picking highly focused libraries for things you dont want to write (crypto, drivers etc.) your self.
I always ended up writing most things from scratch (using stdlib).
So... I agree.
Concurrency support is not needed because that is what the webserver is for.
Yes, in mainstream PHP you use the webserver to leverage forking. The great thing about that is that vastly simplifies the language and any frameworks written in that language. No, it doesn’t force anything to the client.
Also any performance gains made in web server technology is given to PHP for free.
In Java and Python and the like you typically have a thread pool to handle every request, this has the benefit that you can share memory with mutexes between request (threads) . However 99% of cases that is not typically something you want, to have leaky requests, thus most of the time you write code similar to PHP to avoid any hard to debug lock. In Python you also have bad threading performance because of the GIL, thus you avoid anything that steps into that.
Thus PHP share-nothing-model wins again. It is also a natural fit to stateless REST. In PHP you use the database to share memory (data), which is a natural fit in a web stack. And as with the web server you can now leverage any performance gains in database technology.
Nodejs is of course complete trash with the mini freezes of the event loop. And to leverage multiprocess you have to use something like cluster, thus you are back to share-nothing again.
Thus what you argue for is to change a successful request and memory model because of that 1% use case. That is dumb.
Python:
calc.py
-------
def sum(a, b):
return a+b
hello.py
--------
import calc
print(calc.sum(1, 2))
LongUniqueStringToHopefullyAvoidCollisions/Calc.php
---------------------------------------------------
<?php
namespace LongUniqueStringToHopefullyAvoidCollisions;
class Calc {
public static function sum($a, $b) {
return $a + $b;
}
}
hello.php
---------
<?php
require_once 'LongUniqueStringToHopefullyAvoidCollisions/Calc.php';
use LongUniqueStringToHopefullyAvoidCollisions\Calc;
echo Calc::sum(1, 2)
And it does not do away with the problem that you have to preemptively wrap everything in classes and add a LongUniqueStringToHopefullyAvoidCollisions via the "namespace" and "use" keywords to all your classes to hopefully avoid name clashes in the future.
Also when working with projects that are 10+ years and lines of codes a million you will run into this. Sure you can always fork and move the library to another namespace, but that is extra work.
Modules are vastly superior to namespaces, with modules it is the caller that decides the symbol, with namespaces it is the callee.
Another problem with namespaces in PHP is that you can’t put anything into it, like a variable, it is not like namespace in C++. Namespace in PHP is just name added to the class or function name, kind of fake. Don’t get me wrong, it was a pragmatic solution to a real problem and it worked for what it tried to solve, make it easier to share code.
Modules could be elegantly solved in PHP by reusing the internal concept for a class (how it is with enums and interfaces)
Modules would also make it easier to unit test code, because you will not need to worry about a symbol already have been loaded and can’t get unloaded.
With that said I don’t think it the most important feature to focus on, there are others that give more bang for the buck, like string templating and operator overloading.
Now there are proposals to fix function autoloading but it won’t fix variables and constants.
One way to do it better is to implement modules.
In any case - is there any concrete actual real world example in a modern Symfony/Laravel application where you run into issues while using a decent IDE?
PHP has only globals really, no module system what so ever.
and it hasn't been an issue ever. because all userland code lives in its own namespaces.
PHP messed up pretty big when they made this ad-hoc namespace thing.
namespace Me;
function test(){}
———
use function Me\test;
test();
Conflicting package names require you to be working on a very poorly written project (not using PSR-1) or a dependency that is even worse which is fewer and further between since composer.
Try making a working example of it on an active codebin like this one:
And link to it, then we can discuss it.