3 ms·
I can't say this makes a lot of sense to me. If you want an interpreted language that has great threading or multiprocess support, I don't know why you wouldn'
by birken 16y ago
I can't say this makes a lot of sense to me. If you want an interpreted language that has great threading or multiprocess support, I don't know why you wouldn't use Python or Ruby. PHP certainly offers some solid functionality in a lot of places that are very common for web apps, but this is a stretch. A good engineer uses the right tool for the job, no use in fitting a square peg in a round hole.
- z92 16y agoSome people don't search for languages that have threading or multiprocess support, rather simply want the language of their choice to have threading and multiprocess support. This is good news for them nevertheless.
- pilif 16y agoTo expand on z92's answer: In my case, I have a huge web application including a ton of framework code that's powering a frontend. In the backend, there are scripts processing many millions of rows each day. These scripts depend on the framework being available (for example to do certain tasks in the context of a specific user, or just for configuration settings). It's infinitely more useful to be able to actually rely on that framework in these scripts than having to recreate all the environment (or the needed parts of it) every time - especially as the framework might change and the scripts should continue to work. This makes these scripts prime candidates to be written in the same language as the web frontend and the framework, which, unfortunately, means PHP. By being able to easily spawn a few subprocesses from these scripts, I can make them a lot faster while still being able to rely on the standard application environment to be there for them.