[wvenable]

> Lexical scoping

Yes.

> Coroutines

No.

> Generators

Yes.

> Decorators

No.

> Generic type containers

In progress. But also PHP has dynamic/weak typing and static/strong typing so this isn't strictly necessary.

> A functional API (e.g. something like Java 8 streams)

Available as a 3rd party library.

> An extensive selection of data structures (collections) included in the standard lib

https://www.php.net/manual/en/book.spl.php

[codesushi42]

Thanks for the thoughtful response. But based on your answers, PHP does lag significantly behind other modern languages. FYI the SPL you linked is quite meager compared to languages like Python and Java.

My opinion remains unchanged. Using PHP in 2019 only puts you at a disadvantage when compared to the alternatives.

[wvenable]

Honestly nobody uses the SPL. PHP's array type is more than powerful enough for the vast majority of data structure tasks and the standard library has functions for treating it as a stack, a list, etc.

Coroutines are not necessary in PHP. In fact, the share nothing architecture of the LAMP stack is one of it's advantages if that suits your needs.

The setup of a Java web stack alone is painful enough to make PHP a viable option in comparison.

[codesushi42]

Thanks. Again, I am asking out of ignorance:

What is PHP's concurrency model? Is it still a forked process pool via something like PHP-FPM, or has it changed?

Does the VM enforce a GIL? I'm assuming there is some kind of threading API?

Can you run an event loop using epoll, and is the standard library well supported in that execution model?

FYI, I was a PHP developer from 2003-2011. I did enjoy it back then. I never bought into the Rails hype at the time, opting instead for copycats like Yii and CI.

But I was ignorant. Honestly, after switching to Python for web dev, I saw no reason to ever return. Since then, I've dropped web dev altogether, and I now work in C++, Java, and Python on a daily basis.

It may be the nature of the work, but I still cringe at the thought of using PHP again after learning how capable other general purpose languages are. From a CS point of view, working in PHP just isn't very interesting... or pleasant.

[wvenable]

> What is PHP's concurrency model? Is it still a forked process pool via something like PHP-FPM, or has it changed? > Does the VM enforce a GIL? I'm assuming there is some kind of threading API?

As far as I'm aware PHP is still mostly run PHP-FPM. It also does have a threading API: https://www.php.net/manual/en/class.thread.php

> But I was ignorant. Honestly, after switching to Python for web dev, I saw no reason to ever return. Since then, I've dropped web dev altogether, and I now work in C++, Java, and Python on a daily basis.

I haven't done PHP seriously in a very long time. I currently work in C# and ASP.NET for web and I do C++, Python, and JavaScript. Personally, I'm doing work in Python right now and I don't enjoy it very much -- I'd much rather work in PHP for web development over Python. I prefer a good strongly typed language.

> I still cringe at the thought of using PHP again after learning how capable other general purpose languages are. From a CS point of view, working in PHP just isn't very interesting... or pleasant.

I don't know. PHP has Lambdas. It has generators. It was strong typing. From a CS perspective, there isn't much PHP does not have for the purposes of web development. It's limitations, in my opinion, mostly come from being a dynamic scripting language but those same issues befall Python and Nodejs as well.

If I had to code in PHP again, my code wouldn't look much different from my code in any other language.

[codesushi42]

That's fair.

I think if you're building CRUD apps over and over again, then yeah, there isn't too much difference.

But if you're building a web service with more complicated business logic and you need more control over your concurrency model, then other languages look more appealing.

And it looks like PHP doesn't have JIT yet, which is another huge mark against it.

So PHP is probably fine for passing params and rendering back HTML. But anything sitting in between that's more interesting should be built in something else.