[erlang-questions] Benchmarks

[Ulf Wiger]

Vlad Didenko wrote:
> That is really interesting. Where would I read up on which tasks
> Erlang fits really well? I have seen the earlier message from Ulf to
> NavTux about about "non-stop complex control systems". That post,
> again, lists areas which Erlang is NOT focused on. Is there a
> specific positive list somewhere?

Hmm, I was listing tradeoffs, but in doing so, at least I thought
I was also listing some of the areas where Erlang can be expected
to (and does indeed) excel:
- handling lots of concurrent activitites with low latency
- non-stop systems
- handling complex control flows
- run-time tracing and profiling (even with concurrent activities)

The "other side" of micro-benchmarks is that they say precious
little of how the programming language holds up under the ever-
increasing weight of real-world requirements.

My experience is that Erlang is often held up against an ideal
view of what a real-world application written in a mainstream
language would look like, based on micro-benchmarks and
prototypes written by e.g. C++ wizards, the code bearing only
superficial resemblance with the would-be finished product
(the wizards knowing full well which land mines to avoid in
order to write an elegant and blazing fast prototype.)

Just to pick an example that feels fairly current, Google's
Go is often mentioned in blogs and tweets as an Erlang-like
language, since it sports light-weight "processes" and
message-passing. These are extremely useful abstractions, and
you might as well say that it's inspired by C.A.R. Hoare's
CSP model. Notably, however, Go lacks memory protection between
its Goroutines (they share memory and can make use of global
variables with destructive update semantics), and Go completely
lacks support for exceptions. Go may be /perfect/ for many
domains where these are reasonable tradeoffs, but it makes it
a fundamentally different language from Erlang.

Given this fundamental difference in "system semantics", how
should one interpret benchmarks comparing Go and Erlang?
The answer must be that it depends completely on what you
want to do, and how you understand the specific requirements
and acceptable tradeoffs of that problem domain.

BR,
Ulf W
-- 
Ulf Wiger
CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
http://www.erlang-solutions.com
---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com