5 ms·

Ruby on Erlang

18 points by luckystrike 18y ago

bitdiddle 18y ago
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 http://www.diit.unict.it/users/csanto/exat
- davidw 18y ago
  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 18y ago
Why replace Erlang's message passing with a baroque RPC call/return thingy based on that same message passing?
signa11 18y ago
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.
cx01 18y ago
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.
awt 18y ago
Check out the Io language. I think you might like it.
stcredzero 18y ago
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.

18 points by luckystrike 18y ago

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 http://www.diit.unict.it/users/csanto/exat

davidw 18y ago
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 18y ago

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

signa11 18y ago

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.

cx01 18y ago

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.

awt 18y ago

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

stcredzero 18y ago

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.