Erlang (was Re: [PEAK] PEAK and Twisted, revisited)

[John Landahl]

Phillip J. Eby wrote:

> My main target for asynchrony in peak.query will be for change events 
> (facts added/removed) rather than for results.  I anticipate that it 
> will be quite possible to implement async query methodology as well, 
> but I think it adds needless overhead to use something like Twisted's 
> adbapi compared to just writing a half-async threaded or forking 
> server.  Given that in my day job I write apps to run on 
> multiprocessor boxes, I prefer to use half-async + fork as a model for 
> request handling.  Synchronous code is much easier to write than async 
> code, and forking eliminates most worries about race conditions, as 
> well as bypassing any GIL bottleneck.

As an aside, I've been taking a long look at Erlang lately.  Its 
built-in concurrency and message-passing model is beautiful.  I've been 
thinking that peak.events could be used to emulate some of it fairly 
well, though it wouldn't be able to approach Erlang's power and 
robustness, and of course there's no pattern matching in Python, either. 
:(  But I think a lot of the OTP design principles 
<http://www.erlang.org/doc/r9c/doc/design_principles/part_frame.html> 
could be implemented using peak.events; I'm especially interested in 
OTP's supervision model.

BTW, there's a web server written in Erlang (YAWS) which is shown 
capable of handling 80,000 simultaneous connections versus Apache's 
~4,000 on the same platform 
(http://www.sics.se/~joe/apachevsyaws.html).  Impressive, to say the least.