Erlang’s sort of a strange one. Obviously, it can’t be called
academic, and the programming model is entirely based on concurrency,
but at the same time, it doesn’t support native threading. I’ve always
thought that is a strange choice. They have really fast user-space
threading, but it will never use multiple processors unless you’re
running multiple Erlang VMs, and then you have to explicitly start your
thread on the VM of your choice, from what I understand.
I read somewhere about Erlang that the next release of the VM will
support using OS threads for pooling Erlang processes transparently.
I can’t recall though when the referred statement was written – it’s
possible that it was written long before and that “next release” has
came to reality since then.
Still, I love
the language. I wish ruby allowed overloading of the ! operator, just
so I could implement a ruby thread wrapper that could accept messages
with Erlang syntax
Well, in Erlang it’s a principle that processes may communicate only
via the messaging interface. It’s achieved by the (almost) pure
functional semantics. Data is never modified in-place, always copied. A
function (in particular one ran in a process) can see only the values
which were passed to it as arguments (by value).
[Disclaimer: AFAICS, IANAEH]
I wonder how would you enforce this strong separation in ruby… maybe
_why-s shiny Sandbox could be made use of?
support using OS threads for pooling Erlang processes transparently.
I can’t recall though when the referred statement was written – it’s
possible that it was written long before and that “next release” has
came to reality since then.
-snip-
Yes, I should take a look at that. Although … CSP (Occam/Hoare) and
CCS (Milner) cover pretty much the same ground, and the PI-Calculus is a
direct descendant of CCS. I’m wondering what CSP can do that the
PI-Calculus can’t.
I read somewhere about Erlang that the next release of the VM will
support using OS threads for pooling Erlang processes transparently.
I can’t recall though when the referred statement was written – it’s
possible that it was written long before and that “next release” has
came to reality since then.
-snip-
Well, in Erlang it’s a principle that processes may communicate only
via the messaging interface. It’s achieved by the (almost) pure
functional semantics. Data is never modified in-place, always copied. A
function (in particular one ran in a process) can see only the values
which were passed to it as arguments (by value).
How (almost) pure functional? I haven’t used Erlang much, but it seems
to be totally pure-functional from what I can tell. They do use
looping threads to keep state, so side-effects are possible that way,
but is there a way to override defined variables?
[Disclaimer: AFAICS, IANAEH]
I wonder how would you enforce this strong separation in ruby… maybe
_why-s shiny Sandbox could be made use of?
For the places where Erlang is supposed to be used, I suppose that the
extreme separation they use is a really good idea, but I’d love to just
have the syntax available in Ruby. I tend to design a lot of my
programs as processes sending each other messages right now (mind
polluted by erlang, I guess), and just being able to have some nice
syntax for that in ruby would make me quite happy.
Strangely enough, I don’t recall ever seeing a real programming
language, to be distinguished from academic ones, that ever handled
parallelism in a manner other than as calls to run-time libraries. Ruby
already has that.
There’s the Limbo programming language, invented by Rob Pike, Phil
Winterbottom, and some of the other guys responsible for Plan 9, used
in the Inferno operating system [1]. It essentially implements
communicating sequential processes: it incorporates typed
communication channels between processes as a language primitive, and
provides built-in mechanisms for using them for synchronization and
communication. It’s an interesting piece of work, and I for one would
like to see Ruby with similar features in the future.
Well, in Erlang it’s a principle that processes may communicate only
via the messaging interface. It’s achieved by the (almost) pure
functional semantics. Data is never modified in-place, always copied. A
function (in particular one ran in a process) can see only the values
which were passed to it as arguments (by value).
How (almost) pure functional? I haven’t used Erlang much, but it seems
to be totally pure-functional from what I can tell. They do use
looping threads to keep state, so side-effects are possible that way,
but is there a way to override defined variables?
As I heard, you are not prohibited to play dirty tricks with the
few globally accessible data structure like the process table
(although doing that is not considered to be good style).
IIRC message passing is considered a side effect generating call. I
could
imagine a concurrency semantics where it’s not a side effect; I don’t
see how Erlang’s semantics relates to that.
The big beast: I/O. A purely functional language must somehow encode
I/O as environment (world state) passing, like Haskell does it with
monads and Clean with unique types.
Erlang doesn’t want to sink into such abstractions, it just does I/O
as usual.
I wonder how would you enforce this strong separation in ruby… maybe
_why-s shiny Sandbox could be made use of?
For the places where Erlang is supposed to be used, I suppose that the
extreme separation they use is a really good idea, but I’d love to just
have the syntax available in Ruby. I tend to design a lot of my
programs as processes sending each other messages right now (mind
polluted by erlang, I guess), and just being able to have some nice
syntax for that in ruby would make me quite happy.
I don’t see into your mind, but maybe what’s there is closer to the
idea of coroutines than to CSP style models.
communication channels between processes as a language primitive, and
provides built-in mechanisms for using them for synchronization and
communication. It’s an interesting piece of work, and I for one would
like to see Ruby with similar features in the future.
fortytwo :~ > cat a.rb
require 'slave'
class ServerA
def meth() 40 end
end
class ServerB
def meth() 2 end
end
sa, sb = [ServerA, ServerB].map{|c| Slave.new c.new}
p sa.pid
p sb.pid
a, b = sa.object, sb.object
p(a.meth + b.meth)
fortytwo :~ > ruby a.rb
26206
26207
42
So a slave based code is not using a language feature but an OS feature;
it tells nothing (or very little) about the expressive power of the
language. And it neither performs well as a concurrency implementation.
true all. nevetheless it’s an alternative to threads.
So a slave based code is not using a language feature but an OS feature;
it tells nothing (or very little) about the expressive power of the
language. And it neither performs well as a concurrency implementation.
