Sam Ruby's "long bets" don't seem so far off considering how quickly changes are happening on the internets....
By the way, have you seen the erlang "slave" and "pool" libraries? These might not do entirely what you want. Good news: applicable as-is. Even better: they can be (re-)implemented in not-so-much erlang to do entirely what you want.So, without further ado, here’s my long bets for the moment, with the only caveat that in some cases I pick specific implementations as exemplars of a larger field.
Maybe its time really has come.
2 comments:
Not everyone is buying the Erlang hype.
I don't get the point. Erlang does not present a shared-memory programming model. Although Erlang can take advantage of multi-core chips, the model for using Erlang on a multi-core node is no different than for using Erlang on a multi-node environment with single-core, dual-core, or multi-core nodes.
Also Steve's note about tight coupling of data and code "aka object-orientation" also applies to Erlang -- an Erlang process is essentially such a coupling, and the interface to that process is the message protocol.
I think Steve's argument is right in line with Erlang. His argument goes more against the systems that have one model for intra-process and another for inter-process computing. C and pthreads, Java and its threads, even Haskell and its Software Transactional Memory fall into the category the will suffer according to Steve's argument.
Post a Comment