Erlang is a parallel functional programming language designed for real-time control systems, so it aims to provide millisecond-order response times, portability, concurrency, IPC, distribution and to accommodate very large programs and non-stop systems. Erlang uses garbage collection, users can control how code is loaded, it uses error detection for robustness, and has a port mechanism for communication with outside processes. Concurrency is supported by the language environment itself and doesn't require programmers to interact with the underlying operating system.
Error handling in Erlang seems straightforward and particularly useful for distributed/parallel systems. Run-time errors can be used to monitor the evaluation of an expression, monitor the behavior of a process, and raise an exception when an undefined function is called. When a process dies, it notifies other processes about why it died, and the tracking process can re-spawn another process to finish the job (since it's all functional, no state information needs to be reconstructed).
Performance-wise, it looks like Erlang is good for soft real-time systems where performance guarantees are not required, but highly desired (and it seems to have a good track record at Ericsson). While I wasn't surprised that C outperforms Erlang on small benchmarks (to be expected with the gc overhead, etc.), I found it interesting that Erlang does better than C on large systems.
One of the major trade-offs might be Erlang's unfamiliar syntax, which coupled with a functional programming model might impose a steep learning curve for many programmers.
As far as influence goes, it is clear that Erlang has remained influential over the past 25 years -- and continues to be an appropriate choice for applications that require high degrees of concurrency (users of Erlang include CouchDB, Riak, AWS SimpleDB, Membase, and others).
Error handling in Erlang seems straightforward and particularly useful for distributed/parallel systems. Run-time errors can be used to monitor the evaluation of an expression, monitor the behavior of a process, and raise an exception when an undefined function is called. When a process dies, it notifies other processes about why it died, and the tracking process can re-spawn another process to finish the job (since it's all functional, no state information needs to be reconstructed).
Performance-wise, it looks like Erlang is good for soft real-time systems where performance guarantees are not required, but highly desired (and it seems to have a good track record at Ericsson). While I wasn't surprised that C outperforms Erlang on small benchmarks (to be expected with the gc overhead, etc.), I found it interesting that Erlang does better than C on large systems.
One of the major trade-offs might be Erlang's unfamiliar syntax, which coupled with a functional programming model might impose a steep learning curve for many programmers.
As far as influence goes, it is clear that Erlang has remained influential over the past 25 years -- and continues to be an appropriate choice for applications that require high degrees of concurrency (users of Erlang include CouchDB, Riak, AWS SimpleDB, Membase, and others).
No comments:
Post a Comment