> A video streaming service, or most API with response time guarantees ... Preemption, the design of Erlang's GC etc. don't contribute to predictability or rel

> A video streaming service, or most API with response time guarantees ... Preemption, the design of Erlang's GC etc. don't contribute to predictability or reliability any more than other frameworks. Consider a system written in Erlang, and another written using a very different architecture, say Python/C++ (YouTube). In both cases, Python and Erlang are basically used for orchestration; the action happens in the systems layer below. In both cases they use non-blocking I/O underneath, and some sort of adaptive bitrate streaming if not enough bytes are going through within the time bound. There is nothing that is particular to the Erlang system that monitors bitrate and does something about it. In both cases, the soft real time guarantee has to be accounted for explicitly; you don't get it in any shape or form from the Python or Erlang architecture. The only 'guarantee' you get is the promise of using the underlying API in the most sensible way possible, and to push out bytes with as little overhead as possible. What you get in both cases, is convenience. As a side note, here's BBC's Kamaelia framework (http://www.kamaelia.org/Home.html http://www.kamaelia.org/Home.html) written in Python. (I'm not sure if they still use it though).