Erlang vs. other languages, and how easily one could adopt the best
bits of the other. Steve implies, correctly, IMO, that to perform this
kind of assessment requires a fairly good understanding, or at least a
fair bit of research, into the various candidates.
http://steve.vinoski.net/blog/2008/05/09/thinking-in-language-but-not-clearly/
I've seen several attempts to build "erlang in x" where x = common
lisp, python, java, dotnet, etc. To the extent I've followed them they
implement a fraction of the message passing and then don't go much
further. Scala, etc. on the jvm and those on other conventional
runtimes have a problem. Integration with Java instances within those
runtimes is not shared-nothing. You have to remain aware of what is
and what is not following the actor paradigm.
Erlang's JInterface is probably a better integration mechanism in the
long-run than running in the same shared-memory OS process.
As for monitoring, certainly a quick glance would have shown Ted there
is SNMP, as Steve points out. But also isn't the entire
process-linking and supervisor hierarchy an important kind of
"monitoring", i.e. "monitoring for availability"? This is something
all these other platforms lack.
So the more I think about it, the less suited these other platforms
are for messaging amongst themselves *or* for monitoring!
Then I came across Avi Bryant's post on Strongtalk, a high-performance
implementation of Smalltalk, correcting an apparently common
misunderstanding that the speed has something to do with the optional
type checker...
"Why do people make this stuff up? ... Strongtalk was that much faster
whether you used the optional static type system or not. Strongtalk's
optimizing compiler completely ignored the types, and it [types -ed.]
made your program run not one iota faster to add them."
1 comment:
Hi Patrick, I just assumed that the author of the original posting already knew about the ability for an Erlang process to spawn another and link to it so that it could monitor it, because that's what I thought he meant by "having to roll your own monitoring." Apparently, making that spawn_link() call is quite difficult! ;-)
Regardless, I agree with you that there's just no excuse for the inaccuracies that appear in the original article and the followup.
Post a Comment