Learn Erlang in 5 seconds - competition - win a prize

[Richard A. O'Keefe]

I think
	Serge Aleynikov <serge@REDACTED>
misunderstood where I am coming from.
I wrote:

	> Actually, no, it DOESN'T sound impossible with Smalltalk.

I then provided illustrative detail about why it wouldn't even be
particularly hard in the modern Smalltalk I know best.
	
	Every language certainly has merits, otherwise why would it be designed
	in the first place?
	
The point is not that Smalltalk has SOME merits,
but that a decent modern Smalltalk has many of the RIGHT merits to be not
altogether unreasonable for this kind of application.
The central weakness in Smalltalk is the absence of any kind of
encapsulation between processes.  Of course, Smalltalk processes don't
*have* to trample on each other's data structures to get work done, it's
just that it's extremely difficult to be sure that they don't do this
accidentally.  Good discipline and tools could help.  More importantly,
there is no obvious reason why you couldn't have a Smalltalk system
where everything was exactly the way it is now EXCEPT that processes
DIDN'T have write access to each other's data.  (In fact, if I ever get
my Smalltalk compiler finished, that's exactly how I intend to do it.)

If you took Smalltalk, encapsulated process's data from each other,
and added !, you'd have something that would basically BE Erlang with
funny syntax minus pattern matching plus mutable private data (and with
the process dictionary, Erlang already has a form of mutable private
data) plus classes.

I suggest that while cheap processes are very nice to have,
it's process ENCAPSULATION which matters most for Erlang,
because that makes processes easy to THINK about and makes a whole
lot of nasty concurrency bugs impossible.

Process encapsulation also happens to be the thing that makes Erlang
distribution pleasant, because once you can't muck around with another
process's data you stop caring so much which machine it keeps those data on.

	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-alone applications.
	
Yes, agreed.  But a modern Smalltalk is also more than just a language;
a modern Smalltalk *also* has a framework, and thanks to the Web, that
framework includes support for TCP/IP, HTTP, FTP, XML, hot loading, &c.

To be sure, Squeak doesn't have ASN.1 support, but there was a time when
Erlang didn't either, and it wouldn't be particularly hard to add it.
As for application and release versioning, it took years and years of
arguing and experimentation, but eventually something very like that did
go in.

The really really fundamental difference between Erlang and (present)
Smalltalk is that Erlang processes have idiot-proof encapsulated data
and Smalltalk processes don't.

	> 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, slipped a decimal point there.  31.6 milliseconds.

I wrote
		 vvvvvvvvvvvvvvvvvvvvvvvvvvvvv
	> Sorry, for something built in a week I just don't believe it.
		 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

	If we are using the same terms, availability is
[snipped because irrelevant]

	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.
	
I also can easily believe that a system with that level of reliability
(assuming, which I'm not altogether happy about assuming, that failures
are independent; common causes tend to produce common failures) can be
built with Erlang/OTP.

What I *can't* swallow is that a nontrivial system can be built to that
level of reliability in *any* language in just one week.  For a non-trivial
system, it's going to take you at least a week just to understand the
requirements.  It's also going to take a fair while to run adequate tests.

	However, given a reliable network putting together a proof-of-concept 
        vvvvvvvvvvvvvvvv
	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.
	
But that isn't the kind of application we were talking about, far from it.

Heck, I could put together a proof-of-concept simple redundant application
with the traits above in a week using Oz/Mozart (once I've spent the
necessary couple of weeks reading the Mozart reference manuals; it's
already taken me a week to not quite finish the tutorials).  I wouldn't
dream of suggesting that that said anything significant about the
usefulness of Oz/Mozart for a full-blown system.