On Thu, Jul 9, 2009 at 8:20 AM, Henning Diedrich<[email protected]> 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 _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
