On Thu, Jul 9, 2009 at 8:20 AM, Henning
Diedrich<hd at authentic-internet.de> wrote:
> Erlang, got multi-threaded only quite recently, in 2007
Yeah but before that time, you just ran multiple nodes on the same
machine. Threading is a good way to conserve some memory and optimize
though.
> There is a post from 2006 on
>http://mail.python.org/pipermail/python-3000/2006-September/003718.html ,
> Bob Ippolito answering Ivan Krstić:
>> "Candygram is heavyweight by trade-off, not because it has to be. Candygram
> could absolutely be implemented efficiently in current
> Python if a Twisted-like style was used. An API that exploits Python 2.5's
> with blocks and enhanced iterators would make it less verbose
> than a traditional twisted app and potentially easier to learn. Stackless or
> greenlets could be used for an even lighter weight API,
> though not as portably."
> . . .
>> "> * Introduce microthreads, declare that Python endorses Erlang's
> no-sharing approach to concurrency, and incorporate something like
> "> candygram into the stdlib.
>> "We have cooperatively scheduled microthreads with ugly syntax (yield), or
> more platform-specific and much less debuggable microthreads with stackless
> or greenlets.
>> "The missing part is the async message passing API and the libraries to go
> with it."
I don't think that a lot has changed since 2006, except Erlang has
gotten a lot faster, is much better at SMP on a single node, etc. :)
There are also a lot more people using it now, especially in the US.
I still use Python every day for lots of things, but all of our high
concurrency/performance stuff has been written in Erlang since about
the time of that thread, so we have a few years of experience with it.
We build primarily a lot of the sorts of systems that you'd build in a
game (Mochi is a platform for Flash gaming). If I were writing
something massive and game-like I'd probably write the part that talks
to clients and does bookkeeping in Erlang, and have it speak
bidirectionally over JSON or something to pools of Python or
JavaScript interpreters to process all of the game logic. I don't
think many people would enjoy coding lots of game logic in Erlang.
-bob