2 ms·

> Any system in production is soft real-time by that definition. Most systems don't fit in that definition because they don't have deadlines in the first place

> Any system in production is soft real-time by that definition. Most systems don't fit in that definition because they don't have deadlines in the first place. A site like Hacker News is not soft real-time; the faster it loads the better, but there's not a set number of seconds after which a user would give up. A video streaming service, or most API with response time guarantees, would be soft real-time systems. There is a deadline, but it doesn't need to be respected 100% of the time, as users can live with a few dropped frames or out-of-spec responses. > There's really nothing special about Erlang that makes it amenable to "pretty quick" responses. It's not about "pretty quick" but about predictable, reliable response times. The key feature is the preemptive scheduling. Processes can only block a given scheduler for a very short time; all functions in the language that can take a long time to execute are built to yield to the scheduler periodically. So you don't get a slow request because some other request decided to turn a huge map into a string, or run an expensive loop, or block waiting for I/O, or run a GC, etc. This is of course a tradeoff between throughput and latency, because all the yielding and checking comes at a cost. Go is a bit in the middle ground, it also uses lightweight processes, but does not yield as much so a hot loop can block for some time (but also runs faster as a result).

sriram_malhar 9y ago
> 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).
- ramchip 9y ago
  What's missing from your thought experiment is concurrency. Imagine there's 100k people connected to the server. If you make the system in Erlang, you can handle each connection in a separate process, which individually monitors its own bitrate and fetches or sends data with synchronous calls. This makes the code very straightforward. The VM ensures each process won't block the scheduler for more than 1ms or so, so that processes that have short but time critical operations to do (e.g. push a video frame down a socket) get a chance to run quickly, no matter what other processes are doing and whether it's I/O or CPU bound. Kamaelia, gevent, Node.js, etc. do not provide that guarantee. OS threads do, and there are good frameworks based on them (e.g. Celluloid), but they don't scale to more than a few thousands.
  - sriram_malhar 9y ago
    That's a fair point.

sriram_malhar 9y ago

> 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).

ramchip 9y ago
What's missing from your thought experiment is concurrency. Imagine there's 100k people connected to the server. If you make the system in Erlang, you can handle each connection in a separate process, which individually monitors its own bitrate and fetches or sends data with synchronous calls. This makes the code very straightforward. The VM ensures each process won't block the scheduler for more than 1ms or so, so that processes that have short but time critical operations to do (e.g. push a video frame down a socket) get a chance to run quickly, no matter what other processes are doing and whether it's I/O or CPU bound. Kamaelia, gevent, Node.js, etc. do not provide that guarantee. OS threads do, and there are good frameworks based on them (e.g. Celluloid), but they don't scale to more than a few thousands.
- sriram_malhar 9y ago
  That's a fair point.