

Ruby on Erlang - luckystrike
http://blog.antarestrader.com/?p=77

======
cx01
If I understand him correctly, he wants to make all classes into processes and
method calls into message sends. I don't think this would improve performance
in any way.

"Many of the processes will actually be suspended waiting for the next
message, [...]" Exactly. What's the use of making a function call
asynchronous, if the program has to wait for the result? None. It's just going
to generate overhead.

Just a thought experiment: What if I take a program and make every line of
code spawn a process, and the next line wait for the result. It's clear that
this won't improve performance.

------
signa11
problem with reusing syntax from another (more familiar language) (imho) is
that some fundamental/ubiquitous features e.g. pattern matching which
permeates almost everything in erlang, are pretty hard to get right. same
applies for creating objects (by writing them down) and matching against them.

i "feel" that problems are more due to difference in semantics associated with
the syntax, rather than with just the syntax itself.

------
bitdiddle
Interesting thought. One can argue that the ability to write better OO code is
already present in modules, functions, processes, and asynchronous message
passing. Threads are needed in Ruby and Java to handle the asynchronous piece.
Consider also Erlang's pattern matching style of defining functions, which
reminds me a bit of generics in CLOS. Lisp like atoms are also a very useful
device in Erlang.

So it strikes me that this proposal is sort of re-inventing in Erlang
something that already exists. Moreover when one throws in OTP and it's
frameworks for structuring collections of processes, I'm not quite sold on the
benefits of doing this beyond making Erlang accessible to the larger audience
steeped in the OO way.

Corrado Santoro has done a little bit with this in his agent technology
<http://www.diit.unict.it/users/csanto/exat>

~~~
davidw
I'm not sure his approach is a winner, but I do agree that Erlang feels much
slower to use than Ruby, even after taking the time to rejig your brain for
its style of doing things, and I think the idea of layering some more stuff on
top to make it convenient isn't a bad idea at all. Perhaps that 'stuff'
wouldn't end up actually being Ruby, but it's a good starting point.

------
cousin_it
Why replace Erlang's message passing with a baroque RPC call/return thingy
based on that same message passing?

------
stcredzero
Making an uber concurrency friendly Ruby would probably end up looking a lot
like Stackless Python.

Rubinius is going whole-hog on green (lightweight) threads, BTW.

------
awt
Check out the Io language. I think you might like it.

