It introduced such drastic breaking changes, that probably a lot of systems which were previously perfectly serving their users will be abandoned. Projects that could have stayed on the internet and served their users just fine.
It broke the order of parameters in join statements.
It broke calling static functions without the need to declare them as static.
It broke adding properties dynamicly to objects.
It broke easy string handling for many functions where Null was rendered as an empty string.
And these changes make PHP code more bloated. There is now no way around adding more declarations to your codebase than before.
Some of these breakages had 30% votes against them, including the original author of PHP:
The bar for breaking changes should be much higher.
Python's update from version 2 to version 3 caused a lot of pain. But at least it made the code leaner. Allowing users to go from "a=float(b)/c" to "a=b/c" is a good thing. Forcing users to go from "function f()" to "static function f()" is a bad thing.
PHP 8 is the best version of PHP yet, and the main reason why it's so good is precisely because it got rid of a huge amount of ugly, legacy behavior.
Upgrading a codebase to PHP 8 is not an insurmountable task, I've upgraded our 1 million SLOC codebase at work in just a few weeks, with the help of tools like https://psalm.dev and our own strict coding standard.
Yeah I'm aware of Rector, there's a funny story here, I actually created https://github.com/phabelio/phabel which does the same thing as Rector, but @ installation time (fully integrated with Composer!): I created because I simply did not know about its existence, or else I would've just used it, instead :)
Rector is a very nice project, but I still haven't gotten around to integrating it into our codebase at work, because it uses phpstan instead of Psalm, and apart from being slower than Psalm, phpstan kept having various issues and crashes while scanning our codebase, unlike Psalm which mostly worked out of the box (I even became maintainer of Psalm, due to the large amount of additional performance improvements I added due to our needs @ work).
At work, we're currently using Psalm with a few extensions that make some autofixes as needed, a bit like Rector.
It introduced such drastic breaking changes, that probably a lot of systems which were previously serving unsafe and error-prone code to their users will be abandoned. Projects that should have been updated ages ago and served their users dangerous code.
It fixed the order of parameters in join statements.
It fixed calling static functions without declaring them as static.
It fixed adding properties dynamicly to objects.
It fixed string handling for many functions where Null was rendered as an empty string.
And these changes make PHP code more secure. There is now no way around adding more declarations to your codebase than before.
I still remember PHP3... PHP5 was not "horrible in almost any metric", and it was much easier to write secure code with PHP5, which is why "websites running old PHP code are so seldom hacked".
PHP expects programmers not to do stupid things... I guess that is too much to ask in the modern era where "programmers" do not want to have to actually program anything, they instead want make a function statement, then have AI fill in the rest for them, or use a Low Code or "RAD" framework to abstract away all the actual programming so they can do the "fun design stuff" ...
I use PHP for my day job, but the one thing I miss most is compile-time (type) errors. PHP just goes until it can’t go any more. I prefer languages that tell me that I forgot something somewhere, or that a name or signature change broke something somewhere I hadn’t thought about.
How does this statement relate to the comment you replied to? You suppose only juniors appreciate newer versions of PHP? Or seniors don’t know how to port code bases?
Most of the stuff you talked about only causes warnings, unless (and it’s a good practice btw) you’re converting them into exceptions by setting up an error handler.
In my case, I used a combination of Rector, integration tests, and sending exceptions to Sentry to successfully upgrade a PHP code base from version 7 to 8.
I don't think it broke any of that, I think it fixed all of that.
And PHP 5,7 will continue to work just fine for a while. There still supported backports and images of PHP 5 to this day on any major operating system.
We migrated the codebase of our most ancient system (started in 2008) to PHP8 this May. Millions of lines of code. It mostly consists of PHP5-era code, and there's also newer code which is compatible with PHP7. It took 4 weeks of work of 1 dev and 1 QA (including bugfixing). The engineer responsible for the conversion downloaded all existing linters he could find, ran them and fixed code until they stopped complaining. He also he used Rector - software which can semi-automatically update PHP code to newer versions. We had a few non-critical regressions after the release due to the breaking changes, but otherwise I was surprised how smooth the release was. My favorite feature is "constructor property promotion", a lot of classes now take 2 times less code.
Javascript is a client-side language, you don't have control of the software stack, thus (ideally, if you want to) you have to write code to support every version, even a prehistoric chrome build from 2015 (be it directly or indirectly via transpiling and polyfills).
PHP is not like that, like in every other language where you can control the entire environment, it evolves and things break, and that's the way it should be, that's why we have semantic versioning.
It introduced such drastic breaking changes, that probably a lot of systems which were previously perfectly serving their users will be abandoned. Projects that could have stayed on the internet and served their users just fine.
It broke the order of parameters in join statements.
It broke calling static functions without the need to declare them as static.
It broke adding properties dynamicly to objects.
It broke easy string handling for many functions where Null was rendered as an empty string.
And these changes make PHP code more bloated. There is now no way around adding more declarations to your codebase than before.
Some of these breakages had 30% votes against them, including the original author of PHP:
https://wiki.php.net/rfc/deprecate_dynamic_properties
The bar for breaking changes should be much higher.
Python's update from version 2 to version 3 caused a lot of pain. But at least it made the code leaner. Allowing users to go from "a=float(b)/c" to "a=b/c" is a good thing. Forcing users to go from "function f()" to "static function f()" is a bad thing.