Learn Erlang in 5 seconds - competition - win a prize
Fri Aug 25 16:53:41 CEST 2006
Richard A. O'Keefe wrote:
> Serge Aleynikov <> wrote:
> "What if you were to write a system that was OS-agnostic, would easily
> scale to 100,000s of processes, would run on a cluster of machines,
> would offer nine nines of uptime, and would have to be built in a week?
> ... Sounds impossible with Smalltalk? ... Add Erlang to your arsenal
> and see for yourself!"
> Actually, no, it DOESN'T sound impossible with Smalltalk.
Every language certainly has merits, otherwise why would it be designed
in the first place?
An important distinction of Erlang aside from built-in concurrency
support is that its OTP framework allows to build systems/products
rather than collections of stand-along applications.
What do I mean by that?
Recovery from faults, health monitoring, centralized error reporting,
SNMP support with ease of agent extensibility, release handling with
automatic system upgrades, application and release versioning, systemic
use of design patterns or templates that allow development teams to use
the same coding style, and preserve structure of applications therefore
simplifying support of derived products.
Can you do this in other languages? Certainly, if you tackle these
problems individually! Yet /IMHO/ the designers of most languages only
take it to the point of providing developers with a compiler, a VM (if
required by the language), debugging tools, perhaps some IDE, some basic
libraries, and leave it up to the developer to use this in order to
develop products. So the next step that happens is that many developers
use these tools to put together some useful components in a non-systemic
manner. This makes it expensive for companies to use such a language
and libraries for building products, because they have to incur the cost
of assembling pieces together, ensure there exists adequate support for
each 3rd party component, and deal with coding style and other
differences. All of this makes products expensive to develop and maintain.
Frankly, if Erlang didn't come with the OTP, I don't think we would use
it in our work.
> Nine nines of uptime? That's 3 MILLISECONDS of downtime in a year, no?
(86400 s/day * 365 days) * 10^-9 =~= 0.032 s
> Sorry, for something built in a week I just don't believe it. I believe
> it a little bit more for Erlang than I do for Smalltalk, just like I have
> a little bit more belief in mermaids than in vampires.
If we are using the same terms, availability is:
A = -----------
MTBF + MTTR
MTBF - Mean time between failure
MTTR - Mean time to repair
Combined availability of N parallel components would be:
Ac = 1 - (1 - Ai)^N
Let's assume that we have a distributed redundant system composed of
three server nodes running on separate hosts. Using the formula above,
each node must provide 0.999 of uptime, or roughly 9 hours of downtime
I also don't believe in mermaids and vampires, but having deployed such
systems built with Erlang/OTP in a production telecom network, these
numbers don't sound unreasonable.
Well, I should've probably noted something about hardware abstraction.
Building reliable systems that rely on unreliable networks is quite a
big challenge on its own, and Erlang/OTP doesn't help in this area
without additional effort needed to solidify the network architecture,
and implement algorithms that deal with detection and recovery from
However, given a reliable network putting together a proof-of-concept
simple redundant application with the traits above within a week is
certainly not a unreasonable task for a developer with a good knowledge
of the OTP and building distributed applications.
> It is *never* a good idea to insult your audience.
> If you tell a Smalltalk audience that they can't develop distributed
> concurrent systems in Smalltalk they will write you down as an arrogant
> idiot who knows nothing about Smalltalk, and won't hear anything else you
> say no matter how good it is.
Granted that for the word 'impossible' may sound offensive to someone,
the "Sounds impossible with Smalltalk?" sentence can be taken out
safely, shortening the 10s phrase, while still preserving the urge to
explore Erlang. ;-)
More information about the erlang-questions