Hi Vimal,

Node is actually probably fine for concurrency, my snarky comment was more because it's a bit of a joke in the devops/startup communities. When node first came out there was a whole lot of hype about it's performance based on some un-relastic benchmarks.  This lead to it being a big deal with a lot of contractors and small companies that didn't really understand what goes into scaling a SaaS application.  The problem is that javascript just got it's non-blocking io tacked on because it lacked any sort of model to be replaced (Ruby and Python carry around green-threads and GILs as their albatross) so node could achieve true concurrency.  The real catch is most of the time true concurrency is not an issue for web-apps, it's just not needed.

Imagine a typical rails app, when a request comes in nginx receives the request and passes it to the proper upstream (unicorn, php-fpm, ect) this service will spin up a new short-lived Ruby interpreter to answer the request and die.  At any time you could potentially have 10s or 100s of Ruby processes across multiple servers handling requests, and this is really important because at real scale you can't use a single server.  I mentioned the actor model before as before as a popular solution, this is partially for concurrency but much more because the idea of mailboxes and no shared state makes distributed systems much easier.  The reason erlang is so amazing it lets you run one system across multiple boxes and gives you better failover capabilities than most people could even imagine.

The other problem is node.js still has a super immature eco-system.  Concurrency does matter for web-sockets, so in ruby you would use jruby and puma for a project like that.  In a more traditional app unicorn and MRI would be a better choice.  In either case these are mature, tested projects worthy of running in production, node.js lacks options like this to scale out an app on the operations side.

Also node.js is javascript.
-- 
Paul Mooring
Systems Engineer and Customer Advocate

www.opscode.com

From: Vimal Shah <vimals@sokikom.com>
Reply-To: Main PLUG discussion list <plug-discuss@lists.phxlinux.org>
Date: Friday, April 5, 2013 7:55 PM
To: Main PLUG discussion list <plug-discuss@lists.phxlinux.org>
Subject: Re: PHP lifespan

I agree with Eric and Paul. The following is moving off topic a little, since it talks about concurrency performance of Node vs PHP.

Node seems to be the cool kid on the block nowadays in Silicon Valley. It could be a fad, but I think there might be more to it. 

Paul, I'm trying to understand why Node may not good for scaling and/or concurrency. Maybe it's just not as good as Scala? Here are some resources that illustrate why it may be a good contender:

1. This link points to some potential upsides for Node over PHP, specifically concerning user concurrency. Does this only hold true for concurrency of < 1000 users?

2. You may have implied that after some threshold of concurrency (maybe >> 10k users), it may not make sense to use Python / Node or Ruby? If this is so, this link seems to say that Node can indeed handle a large amount of concurrency. This leads me to believe that for scaling, Node may be a good contender? 

3. This also states that actors may not be good for concurrency, at least not anymore? Not sure how accurate this is.

Unfortunately, since I've never actually implemented a Node server with high concurrency myself, most of my ammunition on this position is academic.


On Fri, Apr 5, 2013 at 4:29 PM, Paul Mooring <paul@opscode.com> wrote:
I currently work mostly in the web-ops SaaS space and just wanted to throw in my 2 cents here.  Ruby, Python and node.js are all in the same performance class.  Ruby is perfectly capable of handling a full-scale SaaS app, twitter just goes a bit beyond full-scale.  We (Opscode) recently migrated off running our main code base in Ruby as well.  While twitter and opscode both still run a fair amount of ruby in their infrastructures there's one import thing you missed in your reply, they certainly are not moving to python or node.js because that won't help for real scale.  We moved to Erlang and Twitter to Scala, notice those are both functional, concurrent languages using the actor model for concurrency.

I bring this up not to discourage using Ruby, Python or Node.js (well maybe I would discourage node.js a little ;) ), but to bring up that for 95% of the SaaS business out there the performance of the language/framework will always be irrelevant and if they have less than millions of users performance issues are probably in their code rather than their tech stack.
-- 
Paul Mooring
Systems Engineer and Customer Advocate


From: Eric Cope <eric.cope@gmail.com>

Reply-To: Main PLUG discussion list <plug-discuss@lists.phxlinux.org>
Date: Friday, April 5, 2013 3:41 PM

To: Main PLUG discussion list <plug-discuss@lists.phxlinux.org>
Subject: Re: PHP lifespan

I don't see PHP going away for a long time, unless the PHP core developers fly off into left field and make some crazy decisions.
If I was going to learn new languages, I'd learn:
Ruby - because its becoming ubiquitous, but its too slow for full-scale SaaS stuff, just ask Twitter :)
Python, node.js - for performance. 

Just my two cents.

Eric


On Fri, Apr 5, 2013 at 12:57 PM, Paul Mooring <paul@opscode.com> wrote:
I think most of the technologies you listed got sunk by changes in the tech eco-system as a whole.   FoxPro was killed by MS  but COBOL and dBase are still alive in there own niche's.  I think PHP will suffer the same fate, there's definitely better languages for writing full scale SaaS applications in (Ruby and Python seem like the big front-runners) but for a simple site you want to upload via FTP and forget I see no reason anyone would want to put much effort into "replacing" PHP.

On a related note, much of PHP's reputation isn't really deserved in my opinion.  There's a lot of awful code out there, but it's eco-system now has a pretty scale-worthy stack (laravel/symfony/ect, php-fpm and nginx) and like any language, it has some poor design decisions, but for the most part bad code is due to bad programmers rather than the language itself.

-- 
Paul Mooring
Systems Engineer and Customer Advocate
From: keith smith <klsmith2020@yahoo.com>
Reply-To: Main PLUG discussion list <plug-discuss@lists.phxlinux.org>
Date: Friday, April 5, 2013 12:25 PM
To: Main PLUG discussion list <plug-discuss@lists.phxlinux.org>
Subject: PHP lifespan



Hi,  I do not want to start any flame wars.  I would like to open a discussion though.

I was thinking of what the life span of PHP might be.  I have lived through a number of them.

In the early 80's COBOL was still taught and was in use.  I know it is still around, however I do not think anyone would choose COBOL for a new project. 

I also lived through the whole dBase, Clipper, FoxBase+, and Visual FoxPro cycle.  FoxPro was acquired by M$ 15 or 18 years ago, which started it's slow decline.  M$ finally killed it last year.

So I am wondering about PHP.  What might it's lifespan be?  What might be the next big thing... etc.

I'm interested in hearing your thoughts.

------------------------
Keith Smith

---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss


---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss



--
Vimal (rhymes with Kimmel) Shah
Front-End / Infrastructure Engineer
Sokikom
Mobile: (480) 752-9269
Email:   vimals@sokikom.com
Web:    www.sokikom.com
Follow us: twitter.com/sokikom
Like us: facebook.com/sokikom