Re: Asynchronous

[Dominique Brezinski <dominique.brezinski () gmail com>]

On Fri, Oct 7, 2011 at 12:18 AM, Ben Nagy <ben () iagu net> wrote:
> And that's where I think 'we' are moving. I am not a very good
> programmer, but scaling stuff sideways on multiple machines, and
> machines with many (48, currently) cores is pretty much all I do - so
> there's some chance that I represent a fraction of the programming
> community in terms of ability and goals. I ditched a fairly monolithic
> evented approach when the callback singularity created by adding new
> components made my brain explode, and went back to the unix way -
> small utilities and pipes. For me, it's not a question of 'is it
> harder to debug a complex threaded beast or a complex async beast?' -
> reject the initial premise! (of building a complex beast). Anyway, it
> turns out that once you know how to communicate between your small
> processes on a single machine, it is "simple" [1] to just extend that
> to multiple machines, because all the message buses / serialisation /
> RPC frameworks / cloudy candy toys work just as well over a network as
> on a single box.

Actors is a conceptually simple model for loosely-coupled concurrency.
It has the properties you describe:

http://www.javaworld.com/javaworld/jw-02-2009/jw-02-actor-concurrency1.html?page=1

Any programming model or architecture that has shared state presents
scalability challenges. Thinking in terms of threads and locks on
shared memory resources is terribly restrictive in terms of scale.
Infinite horizontal scalability assumes no shared state between
workers, otherwise the shared-state mechanism will be a bottleneck at
some point. Successful, at-scale services tend to have a single,
robust mechanism for state management, and the workers modify state as
infrequently as possible. This seems consistent with the concept
Sebastian Krahmer describes.

Disclosure: I have used Node.js for some projects. It has its time and
place, but its applicability is not nearly as broad as its pundits
would have people believe. It is a great prototyping tool for
asynchronous messaging applications. If I need to write a web app or
web service, I am likely to use rails for many reasons. For huge,
at-scale services, other requirements beyond language and framework
start to take over. The answer is not simply this or that.
_______________________________________________
Dailydave mailing list
Dailydave () lists immunityinc com
https://lists.immunityinc.com/mailman/listinfo/dailydave