A Senior Developer working mostly with PHP and JavaScript, with a bit of Python thrown in for good measure, all on Linux. My tooling is simple, it's GitLab and JetBrains where possible.
I really need to spend more time looking into how PHP 8 and the end of maintenance for PHP 7.4 next year is going to affect me.
There's a lot to be excited about, and great improvement being made. But I worry that the pace of updates, removal of deprecated features, and smaller maintenance windows will make PHP a less viable choice for organisations going forward.
Writing something from the ground up which takes even 12 months means by the time it's live, the version it was written on only has 12 month's maintenance and then 12 month's security fixes before some features may be obsolete by the language.
If there's a reliance on external components (anything via composer), then there's a lot of dependencies which may break or be otherwise unsupported.
We certainly don't want to go back to the days of PHP 5.6 and the glacial pace of updates. But the current pace may be too fast, and be seen as unstable. Especially seeing as there's still a lot of PHP 5 applications out there refusing to die, and still being supported by some people.
you have a point, we are dealing with a momentum in release cycle and removals. Honestly, I don't know what the future holds, but I do appreciate this huge effort on types.
A Senior Developer working mostly with PHP and JavaScript, with a bit of Python thrown in for good measure, all on Linux. My tooling is simple, it's GitLab and JetBrains where possible.
Part of me thinks PHP 8 will be more or less 7.4 with all the deprecated stuff gone, and a few new bits. If so, then I'm all for it.
Initially I was sceptical about the E_ALL errors by default, but it should force developers to be better. Production servers will have templates configurations through Ansible or similar, so I'm not worried there.
Nikita Popov said that in his experience moving from 7.4 to 8 should be fine. I agree with you, silencing errors by default is not a good thing, so it's a nice evolution.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I really need to spend more time looking into how PHP 8 and the end of maintenance for PHP 7.4 next year is going to affect me.
There's a lot to be excited about, and great improvement being made. But I worry that the pace of updates, removal of deprecated features, and smaller maintenance windows will make PHP a less viable choice for organisations going forward.
Writing something from the ground up which takes even 12 months means by the time it's live, the version it was written on only has 12 month's maintenance and then 12 month's security fixes before some features may be obsolete by the language.
If there's a reliance on external components (anything via composer), then there's a lot of dependencies which may break or be otherwise unsupported.
We certainly don't want to go back to the days of PHP 5.6 and the glacial pace of updates. But the current pace may be too fast, and be seen as unstable. Especially seeing as there's still a lot of PHP 5 applications out there refusing to die, and still being supported by some people.
you have a point, we are dealing with a momentum in release cycle and removals. Honestly, I don't know what the future holds, but I do appreciate this huge effort on types.
Part of me thinks PHP 8 will be more or less 7.4 with all the deprecated stuff gone, and a few new bits. If so, then I'm all for it.
Initially I was sceptical about the E_ALL errors by default, but it should force developers to be better. Production servers will have templates configurations through Ansible or similar, so I'm not worried there.
Nikita Popov said that in his experience moving from 7.4 to 8 should be fine. I agree with you, silencing errors by default is not a good thing, so it's a nice evolution.