Is this meant to be run on a web hosting service that supports PHP in the 'traditional' way or do you need permission to run this as a daemon?
If it's the former, I can definitely see its benefits, but if it's the latter I can only imagine the target audience being people who refuse to program in anything but PHP and people who are by some bizarre policy required to use PHP but are allowed to run their own HTTP server.
Let me preface this with a full disclosure:
I've also waded into the depths of many of the PHP APIs that the OP has used to produce this project. I've created a general-purpose PHP daemon library (http://shaneharter.github.com/PHP-Daemon/).
There is no question that the PHP implementation of these APIs (think: Socket, SystemV, POSIX, etc) is very underwhelming compared to something you'd get in Python, Java, or nearly any language. And it's partly because of that that I felt it would be irresponsible for me not to include a disclaimer at the top of my github readme:
For many reasons PHP is not an optimal language choice for creating servers or daemons. I created this library so if you must use PHP for these things, you can do it with ease and produce great results. But if you have the choice, Java, Python, Ruby, etc, are all better suited for this.
So that being said:
With a general-purpose daemon library, there's a 3rd use-case to what you described: People who need to create daemons/servers/etc that use a large existing codebase: maybe it needs to share the 80 models that run your primary website. Maybe you've written a large domain-specific library. That sort of thing.
While it's a little more difficult for me to apply those reasons to a Tornado port, I'd like to hear from the developers first before I dismissed their work.
I'm interested as to how you'd run it as a server without PHP 5.4. Looking at the code, it's written to be compatible with PHP >= 5.3.2, and the composer.json doesn't specify 5.4 as the minimum version.
It also wraps Silex and includes Guzzle (some sort of API consuming thing). Trying to gain credibility from using Node's name seems a little disingenuous given that it's microframework with an event loop of some sort plugged in, and an analogous 'hello world'.
>>I can only imagine the target audience being people who refuse to program in anything but PHP
Such people exist in every language community. You name the famous language and there you will fine people wanting to do everything in that language. This is nothing to specific to php.
There are various reasons for that, Once a person learns a language it becomes an investment- In time and other things and, as time grows out a person begins to think in that language, its paradigms, its idiomatic way of working. He may learn more than one language. But he will bear allegiance to one specific language.
How is PHP's garbage collection for these kinds of things? Usually, it doesn't need to be that good as you can just release all the memory after a request is processed in the typical way PHP is used.
Anyone have experience running PHP-based daemons or things like that? If your React/NodePHP-application crashes on a 'Allowed memory size exhausted' every two days, it'll get old quick.
5.3 and 5.4 are a lot better, but I can't say I'd use them for long running daemons. Personally, I usually use Python daemons that spin up a PHP instance if they need.
I created a server-less distributed network composed by PHP daemons some years ago, it was really fun seeing them linking, automatically discovering new nodes and distributing a task among the available nodes.
We chose PHP because it was the only technology supported in the company, who didn't want to invest on consultancy, research, just do it now, you know.
It was fun, but eventually PHP bad memory management became the main issue, so we were restarting daemons that would crash at random times, often in the middle of some tasks, other times while idle.
Today, I would never create a new project like that using PHP, it doesn't make sense. PHP is great for templating, scripting, and there are some nice frameworks for the classic web applications. However each language has some limitations, an engineer should know much better than that.
For some these php-but-like-node.js projects are abominations but there are a few reasonable use cases.
Of course the vast majority of php and the php 'class library' isn't appropriate for this programming model but neither was most of the existing js corpus before people built an ecosystem around node.js.
Actually, a surprising amount of JS code was already built around event-driven IO. It took a remarkably small amount of work to get YUI3 running on node, for example.
It should not be surprising that this can be done in php.
The libevent extension for event driven non-blocking I/O has been added some time ago. Together with many nice new features since PHP 5.3, including improved garbage collection and speed improvements, it naturally follows that php will be used for these things.
Btw, the libevent extension is really fantastic. If you're doing server programming, take a look at it, it will turbo-charge your server http://php.net/manual/en/book.libevent.php
Perhaps php lost some if its sexiness, but it's still rapidly evolving and improving.
To say this is a port of Node is to misunderstand 99% of what node is. In fact i dont really understand why you even relate this to node at all and why you use the node logo. Call it evented php or or a port of Tornado or something but its not node. If you want to learn what node is listen to Nodeup. Its an awesome podcast with core node people in it that talk about what node is and why it is what it is and why javascript is so integral to it.
I think it's not a joke. look at the source code on github.
But I can't understand this elitism. Programming language choice must not be a cult. Anyone should be free whatever language they like to use whatever they want to do.
So bringing something good or seemingly good to any ecosystem should not get bad responses. They are trying to combine two worlds into a "new choice". Let them do even if yo do not like it. Nobody asks you to praise but just don't give uninformative bad responses.
PHP doesn't have closure like JavaScript. JS accomplished language for evented approach. Because JS have got closure, cascaded scope and prototype chaing.
Hate to burst your bubble, but "how revolutionary node.js is" has very little to do with anything. For example, Vert.x is a formalization (albeit a good one) of Netty-based practices we've been using for years in the Java ecosystem--I've got a "Vert.x prototype" in my projects graveyard and it's been there for years. Pretty much the same idea, though with a lot less love poured into it.
Don't get me wrong, I like Vert.x's API quite a lot and it's why I'm looking at using it. But it's not really "new", it just has a nicer coat of paint. And claiming that node.js is "revolutionary" because of it is a fairly criminal disservice to the ridiculously smart people behind Netty, Mina, and similar projects that have been around for a long time.
[+] [-] Edootjuh|14 years ago|reply
Is this meant to be run on a web hosting service that supports PHP in the 'traditional' way or do you need permission to run this as a daemon?
If it's the former, I can definitely see its benefits, but if it's the latter I can only imagine the target audience being people who refuse to program in anything but PHP and people who are by some bizarre policy required to use PHP but are allowed to run their own HTTP server.
[+] [-] encoderer|14 years ago|reply
There is no question that the PHP implementation of these APIs (think: Socket, SystemV, POSIX, etc) is very underwhelming compared to something you'd get in Python, Java, or nearly any language. And it's partly because of that that I felt it would be irresponsible for me not to include a disclaimer at the top of my github readme:
For many reasons PHP is not an optimal language choice for creating servers or daemons. I created this library so if you must use PHP for these things, you can do it with ease and produce great results. But if you have the choice, Java, Python, Ruby, etc, are all better suited for this.
So that being said:
With a general-purpose daemon library, there's a 3rd use-case to what you described: People who need to create daemons/servers/etc that use a large existing codebase: maybe it needs to share the 80 models that run your primary website. Maybe you've written a large domain-specific library. That sort of thing.
While it's a little more difficult for me to apply those reasons to a Tornado port, I'd like to hear from the developers first before I dismissed their work.
[+] [-] vog|14 years ago|reply
However, for existing projects and/or existing teams there might be another reason to stick with PHP: As a common denominator across all team members.
[+] [-] FuzzyDunlop|14 years ago|reply
It also wraps Silex and includes Guzzle (some sort of API consuming thing). Trying to gain credibility from using Node's name seems a little disingenuous given that it's microframework with an event loop of some sort plugged in, and an analogous 'hello world'.
[+] [-] kamaal|14 years ago|reply
Such people exist in every language community. You name the famous language and there you will fine people wanting to do everything in that language. This is nothing to specific to php.
There are various reasons for that, Once a person learns a language it becomes an investment- In time and other things and, as time grows out a person begins to think in that language, its paradigms, its idiomatic way of working. He may learn more than one language. But he will bear allegiance to one specific language.
[+] [-] michh|14 years ago|reply
Anyone have experience running PHP-based daemons or things like that? If your React/NodePHP-application crashes on a 'Allowed memory size exhausted' every two days, it'll get old quick.
[+] [-] rmccue|14 years ago|reply
[+] [-] dewiz|14 years ago|reply
We chose PHP because it was the only technology supported in the company, who didn't want to invest on consultancy, research, just do it now, you know.
It was fun, but eventually PHP bad memory management became the main issue, so we were restarting daemons that would crash at random times, often in the middle of some tasks, other times while idle.
Today, I would never create a new project like that using PHP, it doesn't make sense. PHP is great for templating, scripting, and there are some nice frameworks for the classic web applications. However each language has some limitations, an engineer should know much better than that.
[+] [-] lux|14 years ago|reply
[+] [-] hinathan|14 years ago|reply
https://github.com/hinathan/edges-php#summary
For some these php-but-like-node.js projects are abominations but there are a few reasonable use cases.
Of course the vast majority of php and the php 'class library' isn't appropriate for this programming model but neither was most of the existing js corpus before people built an ecosystem around node.js.
[+] [-] IsaacSchlueter|14 years ago|reply
[+] [-] flashmob|14 years ago|reply
The libevent extension for event driven non-blocking I/O has been added some time ago. Together with many nice new features since PHP 5.3, including improved garbage collection and speed improvements, it naturally follows that php will be used for these things.
Btw, the libevent extension is really fantastic. If you're doing server programming, take a look at it, it will turbo-charge your server http://php.net/manual/en/book.libevent.php
Perhaps php lost some if its sexiness, but it's still rapidly evolving and improving.
[+] [-] FuzzyDunlop|14 years ago|reply
[+] [-] IsaacSchlueter|14 years ago|reply
(It isn't.)
[+] [-] triathlete|14 years ago|reply
[+] [-] KonradKlause|14 years ago|reply
http://blog.fefe.de/?ts=b1b92654
[+] [-] Kiro|14 years ago|reply
[+] [-] DanWaterworth|14 years ago|reply
[+] [-] rheide|14 years ago|reply
[+] [-] nodesocket|14 years ago|reply
[+] [-] lstoll|14 years ago|reply
[+] [-] 1SaltwaterC|14 years ago|reply
[+] [-] usamec|14 years ago|reply
[+] [-] fsniper|14 years ago|reply
But I can't understand this elitism. Programming language choice must not be a cult. Anyone should be free whatever language they like to use whatever they want to do.
So bringing something good or seemingly good to any ecosystem should not get bad responses. They are trying to combine two worlds into a "new choice". Let them do even if yo do not like it. Nobody asks you to praise but just don't give uninformative bad responses.
[+] [-] obiterdictum|14 years ago|reply
[+] [-] paulbjensen|14 years ago|reply
[+] [-] adeelk|14 years ago|reply
[+] [-] Joeboy|14 years ago|reply
[+] [-] mmaunder|14 years ago|reply
[+] [-] Kudos|14 years ago|reply
[+] [-] tdot|14 years ago|reply
[+] [-] notJim|14 years ago|reply
[+] [-] import|14 years ago|reply
[+] [-] smagch|14 years ago|reply
[+] [-] eropple|14 years ago|reply
Don't get me wrong, I like Vert.x's API quite a lot and it's why I'm looking at using it. But it's not really "new", it just has a nicer coat of paint. And claiming that node.js is "revolutionary" because of it is a fairly criminal disservice to the ridiculously smart people behind Netty, Mina, and similar projects that have been around for a long time.
[+] [-] benschwarz|14 years ago|reply
[+] [-] Zash|14 years ago|reply
[+] [-] gcb|14 years ago|reply
[+] [-] tknew|14 years ago|reply
[+] [-] endymi0n|14 years ago|reply
[+] [-] gpmcadam|14 years ago|reply