[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.
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.
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
More information about the FoRK