It's really good seeing PHP keep to a solid and reliable release schedule. With the creation of the PHP Foundation to ensure that there are actually developers getting paid to work on PHP I think the future for the PHP core is looking rather bright.
Existing familiarity with a python-like language? Lack of motivation to learn the intricacies of PHP? (valid reasons and I'm not trying to sound sarcastic here).
Fibers were released in 8.1 but are there improvements in 8.2?
I'm curious to see how useful it is until a lot of core libraries (curl, redis, mysqlnd, etc) can be called non-blocking and/or trigger a fiber yield during a block? My understanding is swoole does a whole lot of work to enable hooking into those to allow coroutines, which won't implicitly exist with fibers?
IMO, unless I am mistaken, using a continually running PHP process like Swoole removes advantages you get with vanilla PHP: fully isolated requests, file based routing, etc.
This is why fibers are so big. It'll bring performance without the downsides.
Coroutines have been available via many packages for a while; (Open)Swoole and Amp come to mind, but there are probably others. Laravel has supported using (Open)Swoole via Octane for over a year. Why would having coroutines as fibers in the core be a gamechanger?
> Why would having coroutines as fibers in the core be a gamechanger?
Plenty of technical reasons but for me, the biggest is unity among libraries/technologies. There been versions of coroutines/fibers around PHP for many years, first time I heard about it was a PHP fork that implemented fibers, don't recall the name but must have been something like 10 years ago...
But the problem has always been that you cannot rely on the community having things like that available.
Having it in the core language, means that more libraries can depend on it, and users are therefore incentives to learn more about it, as they can rely on it sticking around.
Overall, I'm happy it's coming into the core language.
> Having it in the core language, means that more libraries can depend on it, and users are therefore incentives to learn more about it, as they can rely on it sticking around.
Symfony 6.1 and the upcoming Laravel 10 require PHP 8.1+, but I don't see them using fibers yet. We'll have to wait and see.
I enjoyed PHP at one point. I wrote frameworks, ORM's, NLP, template engines, etc..
Then I discovered Go which is like a grown-up version of PHP. Really simple to get started, solid standard library (PHP relies a lot on extensions), and fixes all the little things like formatting/styling, testing, error handling, benchmarking, modules, and parallel code execution.
It does all this in much less memory and is much faster.
Go is an excellent replacement for PHP when you start hitting the limits of little Laravel apps.
Oh sure, but getting developers to jump from PHP to Rust is a lot harder. Conversely, it's easier to get PHP developers to jump to Node.js despite all it's issues as well.
I mean, Go is still miles above scripting land. 75% of all the cloud computing projects are in Go and if you deal with micro services you'll find a lot of the tooling and systems are written in Go.
If you're using PHP, then Go or Java is much easier upgrade path than Rust.
Historically up to this point, I don't see anything that would have prevented you from doing most excellent things in this world, if PHP was the last and only programming language you had ever learned or known about.
Has anyone made FFI bindings so we can write kernel modules in PHP yet?
I mean all this push for "Rust in the kernel" is nice and all, but do we really need fancy things like "transitive equality"? They have played us for absolute fools.
Sometimes you just want a language that really puts in the work to find a reason why "0x10" == "16z" should be true, no matter what kind of improbable implicit casts have to be done to get there.
PHP makes the impossible possible, and you've got to keep life interesting or it would be too predictable!
I got into programming websites with PHP at a time when everyone was yelling Node for everything, JavaScript frameworks for everything, SPAs for everything.
I absolutely agree they have their place... but I don't have regrets. I'll get into JS Frameworks, Node, and all of that later as it never, ever hurts to broaden experience, but I have no regrets with jumping into PHP first because the productivity level is fantastic when tied to a framework to avoid the footguns. PHP has footguns, some infamous, but so does any framework or language.
A template language that requires manually calling htmlspecialchars on every single value (or else you have an XSS vulnerability) seems like an enormous footgun. In Django this problem was corrected before the 1.0 release.
PHP isn't really used as a template language any more. Most people use a different template language for the views. I've implemented two myself[0][1] but an early one was Smarty[2] and there are many others. I hear Twig is pretty good[3].
If you're not using it as a template language though, why use PHP in the first place? Having to use a separate framework puts it on equal footing with every other language.
it just works with no fuss. no compiling. no memory leaks because it dies after every request. the standard library, despite being horrifically inconsistent, has everything you need
Are you talking about outputting unsafe user input? Laravel is the Django of the php world and does that out of the box. You could clean your user input before storing/displaying as best practice suggest.
