[FoRK] Multicore, async segmented sequential models, Re: outsourcing back end

Stephen D. Williams sdw at lig.net
Wed May 8 13:40:05 PDT 2013


On 5/8/13 9:07 AM, Joseph S. Barrera III wrote:
> On 5/8/2013 2:15 AM, Stephen D. Williams wrote:
>
> > As this points out, you can get multiple processes to handle connections on a single listener in Linux:
> > http://developer.yahoo.com/blogs/ydn/multi-core-http-server-nodejs-8037.html
>
> Yes, and I'm still chewing through that article plus your responses to it.
>
> But it all seems a bit bolted-on, trying to make node.js do something it wasn't designed to do.

I don't feel that way about it too much.  node.js solves a particular problem of efficiency and app code organization and 
orchestration.  Scaling that to multiple cores at the front-end connection, which it already solves at the IO and task delegation 
level, can be a separable problem.

I'm interested in the following as default app server environments, separate from hosted solutions like Heraku:

  * Java Spring / Tomcat etc. as a standard Java environment (but not much of the whole J2EE mess, nor SOAP complexity).  In
    general, fighting obsolescence perhaps.
  * Java Play seems interesting at a glance as one of the newest takes in Java of newer paradigms.
  * Node.js, cool parts in C/C++, Javascript is both good and bad.  I can appreciate the likely minimal app dev overhead and
    potential for efficiency.
  * nginx: web server with efficient, lightweight event / message orientation.  I often just want to write in modern C++, either
    C++11 or Qt+C++11.
  * Can't get into PHP, Python, RoR, .Net, etc. at all so far. Jumped the shark at this point.


Interesting apps are going to be HTML5+Javascript or native Android/iOS/Qt apps talking an async combination of contextual/stateful 
and stateless API with various kinds of federation for ID, auth, and services.

For me, I want the optimal zone of minimal concise but scalable development, rich modern services with features, plugins, and/or 
marketplace, and both local dev, easy local cloud, and multiple commercial commodity cloud services.

>
> So... do you (or anyone else here) have any experience with Erlang? Of course, now we're away from the "same language on client 
> and server", but that's probably the less interesting aspect of node.js.

I learned enough Erlang a few years ago to fully understand RabbitMQ, partly to debug performance issues and to debunk the 
group-think false assignment of magic to what it would provide. Erlang is OK, but making context switching and concurrency 
constraints integral to the language and environment doesn't mean that they don't happen.  The Erlang framework is reasonable for 
writing a lot of message event handling code, like RabbitMQ.  I'm much less excited by it as a general purpose app development 
environment.  You're just going to have to escape to C++ etc. for image processing, serious machine learning, etc.

>
> - Joe 

sdw



More information about the FoRK mailing list