[erlang-questions] Erlang is *not* a implementation of the Actor model Re: Go vs Erlang for distribution

[Richard A. O'Keefe]

I've been reading the ActoScript paper, and am quite confused.
The title of the paper is
	ActorScript(TM)
	extension of C#, Java, Objective C, JavaScript,
	and System Verilog
	using
	iAdaptive(TM) concurrency
	for
	antiCloud(TM) privacy and security

So the title says it's an extension of several other languages
(one of which is notorious for not having any concurrency).
But then what the paper describes is variant of the actor
language from long long ago making use of quirky Unicode
characters, talking about an ActorScript-specific IDE, and
making strong claims of efficiency.  The Tutorial
http://arxiv.org/pdf/1008.2748v20.pdf uses slightly different
syntax.

So what _is_ it?  Is there such a thing as an ActorScript
implementation I could download or buy?  ActorScript,
iAdaptive, and so on seem to be products or services of
a company called UltraConcurrent, Inc, which has apparently
applied to trademark the name WHACK-A-MOLE.  It's remarkably
hard to find anything useful about them; there are a couple
of GoogleDocs that are technically in the trash.  The link
for ActorScript there is to actorscript.co, which does not
exist, nor does actorscript.com.  There's a link for iadaptive.co,
which doesn't exist, while iadaptive.com is blocked here on the
grounds that it contains pornography.

http://carlhewitt.info has lots of links to papers &c but
I am still searching in vain for the *expected* evidence
that ActorScript is something other than vapourware.

I say *expected* because the Actor model has been around for
a long time, Hewitt is a highly respected researcher, and I
trust him not to talk about ActorScript as an existing thing
if it isn't.  But I'd certainly like to see some non-trivial
examples of code and some performance measurements to back up
claims like "ActorScript programs are as efficient as the same
implementation in machine code. For example, message passing
has essentially the same overhead as procedure calls and looping."
Surely there must be *some* measurements somewhere to back this
up, but I have spent several hours looking.

I guess I'm just going to have to keep on using Erlang...

I sometimes think that the most innovative idea in Erlang
is links.  Oh, the way a downstream crash in a Unix
pipeline can take out earlier members of the pipe is
sort of similar.  I wonder if that could have been one
of the inspirations for the idea?

ActorScript has "Swiss cheese" (which seems to be not entirely
unlike monitors, to the very limited extent that I understand
it), but not (again, ttvletiui) links.