Hacker News Reader

Comment by alex-zierhut | Hacker News Reader

The last few years have brought insane progress to the PHP language. I absolutely love the direction. Personally, the next feature I'd like to see the most is a great implementation of Tasks / Asynchronously, something the language always lacked, possibly because it is nearly exclusively used with web servers. I mostly get around that by extensively using queues, software like RabbitMQ, and spawning micro services. I would like to see it move towards more general purpose usability.

View on HN

PHP is currently my favorite language to work in, especially as a freelancer who needs to just get things implemented quickly. No strange docker log issues like I've had with python/node stacks of errors not showing in docker logs until a service restart; just reload a page and bam.

This is more related to how you deploy PHP or Python to the languages themselves...

Well, PHP is specifically optimized for that usecase, with opcode caching etc. Python doesn't do well when initialized on every request.

isn't this what pyc's are? what's the difference?

It sounds like they're talking about deployments where a new process is spawned to handle each request, but for the most part no one deploys Python web apps that way, so I'm not sure.

PHP may have some advantages in terms of deployment, so I guess it's a question of whether those advantages outweigh the potential advantages of using Python for development, which is of course subjective/situational.

It's because PHP uses a CGI process-per-request style model, while there's no good or modern for support in Python for that execution model these days (the community is built around WSGI and ASGI instead). Opcode caching isn't actually relevant because PHP reuses the processes and in-memory structures these days as much as possible.

Have you ever dropped a frame while debugging and fixing it on the fly in a debugger?

I think you miss out if you feel that this is a win when doing PHP.

Just be a real cowboy and use pcntl_fork()

Partially not kidding - I've used this as far back as 2004 to build cron jobs that pull a dataset, split it into N subsets, then fork out into N children to process those subsets of data in parallel. It's certainly not fluid like tasks and it creates a lot of memory duplication if you fork AFTER your data is pulled, but it works surprisingly well. Parent thread can wait for children to finish and even message children through socket pairs (or pcntl_signal for very basic stuff). I agree that it would be nice to have a native abstraction for tasks with messaging and concurrency limits built in.

Fyi someone took pcntl_fork() in PHP seriously and made WorkerMan: https://github.com/walkor/workerman/blob/515ed41ac4fc51fc995...

A quick test got me 50k req/s HTTP "hello world" on my laptop.

The madlad even managed to place PHP in top 22 TechEmpower benchmark: https://i.imgur.com/6fKUpbV.png

It's surprisingly fast. I think they extended it to create copy-on-write memory at fork time, which made it incredibly fast and low-overhead to fork.

PHP seriously needs an event loop. The Node model, where things that call into libuv to wait on servers and such prevent the script from exiting, is simple enough to implement and while mildly unintuitive to newcomers is still accessible thanks to Node's popularity.

As long as from the programmer's perspective it's opt-in rather than opt-out—that is, "await" by default. That was a huge mistake for Node and will seemingly haunt it forever.

PHP has support for event loops, including libuv. See https://reactphp.org/ you can build performant websocket servers with this.

If anything the NodeJs model is trickier to scale because it requires discipline to never block the loop unnecessarily.

PHP/Go/C# one-thread-per-HTTP-request also requires less cognitive load where everything is synchronous by default. Also PHP's throw-away-everything after each request tolerates much more junior-code abuse.

Forgot to close a database connection or transaction? No problem, PHP will do that for you. Left a file open? Forgot to close a CURL handle? No worriers the janitor is coming to clean your mess at the end of the request.

With that said, PHP does have an event loop. See ReactPHP and Swoole. They existed for years and while they have their uses, they aren't going to overtake "standard" PHP execution model anytime soon partly because of the reasons above.

Like Fibers? https://www.php.net/manual/en/language.fibers.php

Fibers don't run concurrently with the main thread. They're like preemptive multitasking, not simultaneous multitasking.

For example, if you have a long-running database query, disk I/O, or some other blocking function, you can't simply send it to the background and do something else while waiting for the result. Network requests are better, but only because the underlying functions support a rudimentary form of async calling.

Someone has apparently implemented async library with fibers and stream wrappers.

https://www.reddit.com/r/PHP/comments/u80gyg/true_coroutines...

> The last few years have brought insane progress to the PHP language

I’ve been hearing this for ~20 years, and yet somehow I still find it more painful to use than other languages that didn’t even exist 10 years ago…

(Except for “being easy to deploy on any random bargain-basement shared web host”, which is a hugely important factor where PHP is genuinely best-in-class and no other language even seems to care about competing, and is the reason that I still regularly need to use it)

The real problem with PHP was always the standard library and its many caveats, outright bugs, and inadequacies, rather than the PHP language itself (there's a few language issues as well, but I found those less painful than the standard library).

A few of these things have been fixed, but by and large the situation has remained unchanged for a long time. It's not an easy problem due to compatibility reasons; adding new language features and such is comparatively easy.

This. PHP is PHP just like Javascript is Javascript. Their growth process was a bunch of people needing things and just implementing them one by one without a grand design. It kinda works, but it'll never be Good in a theoretical sense.

Disturbingly for us language geeks, it doesn't seem to matter at all that they're not very good.

PHP has value types - the one "every data structure at once" type gets deep copied when you pass it to another function. That's enough to make it a good programming language, whereas Python is unnecessarily 90s class-based OOP with reference types.

I don't quite understand what you mean here. Do you have an example?

If you have a dictionary and pass it around to someone else's code and it gets changed, those changes affect your code too instead of copying it, which is annoying and less safe.

Reply on news.ycombinator.com