Erlang is getting too big (Long and a lot of shouting :-)
Tue Oct 14 10:01:42 CEST 2003
Is Erlang big?
Should it grow?
Before we all get to overexcited about this I'd like to get my own 5
cents in ...
When discussing language design/properties all things are not
equally important - we are talking as if they were.
For many years I have thought about what makes a language successful.
Here are two good answers:
1) - Somebody makes money by using language X
2) - X is superbly good at solving some particular problem
that no other language can solve adequately
The guy who say 1) also said (paraphrased) " I became interested in
Erlang because I discovered that people were prepared to invest
their own $ in it".
For point 2) - sure you can write anything in any language (Turing
equivalence) - but this does not mean it is equally difficult. I guess
if Erlang is 10 to 100 times better than language X for a particular
application then it has some chance of succeeding in that particular
So to succeed 1) and 2) have to satisfied
<< note I haven't mentioned deep guards :-) or parameterised modules >>
Simplicity (though I love it) is not on my list - whatever else Java/C++/Perl
have it's certainly not simplicity ...
Cobra and the XML morass are certainly not simple ... and programming things
like the windows API are so complicated that entire tool-making industries have
emerged to try and hide bits of the complexity.
Entire armies of consultant *love* complexity -
Complexity = Job opportunities
Back to the argument.
IMNSHO Erlang is good at concurrency.
It should be is was DESIGNED TO BE GOOD AT CONCURRENCY (The guy four
doors down the corridor wonders why I am pounding the keyboard so
I think (I KNOW) that language changes that are aimed at improving
the concurrency are essential. The world will not stand still - what
we have done with processes in Erlang will one day be done in Java/C#
So what should we do?
I have said this before:
- Improve the *isolation* between processes
This I consider the single most important change to the language.
I consider ISOLATION (you're banging the keyboard again) to be the
single most important property that a language has.
What is ISOLATION?
Two processes are isolated if one process cannot bugger up another
This is "pretty easy to achieve" on different machines. Suppose I
run one process in Sweden and the second process runs on Richard
O'Keefe's machine in new Zealand - suppose I write in Erlang and he
writes in smalltalk - then I hope errors in my program would not crash
The *difficult* bit is doing it on the same machine in the same
What is it that buggers up software projects - bugs in one program
propagate to other programs.
-- Yikes Gadzookes bother and blast - my incomparably beautiful
fault-free well tested program crashed because I linked it together
with a program that contained an error.
The only way that I know of to stop errors propagating is to use
processes (ie virtual machines) - PROCESSES ARE USED TO STOP THE
PROPAGATION OF ERRORS.
Erlang was designed for large software projects.
The principle reason why large software projects fail is because the
software never works.
The main reason why software doesn't work is that errors propagate between
modules - bad code buggers up good code.
Unless you can stop the propagation of errors you will never be able
to write any decent software.
For this reason I do not care about syntactic sugar.
Where should we be going?
* improve concurrency
I'd like to see more processes with better isolation -
* GC of everything
atom tables, code
* First Order Code
First order code with GC would be *wonderful* - even better than
structs (which is just sugar)
* Agent extensions
SECURITY (sorry I'm shouting again)
This is the "wrapper" stuff I keep yacking on about - integration
of UBF contracts with the language.
We should not add things which makes programming a little bit more
convenient (which is after all what a lot of the language changes do) -
we should add thing so we can easily write applications that nobody else can
Erlang is good at one thing - making large reliable systems.
That is what it was designed to do - so YES to all changes aimed at
making it easier to build reliable system software - NO to everything else.
PS - any pleeeeese add the version number of the language to files.
-version(5.0). <--------------- the language version
Then If we do change the language the compiler can figure out what
More information about the erlang-questions