Could Ruby be a good Erlang-like?

ruby-talk
1

Hi,

After writing this post on the possibilities to add some features from other languages to Ruby: http://etorreborre.blogspot.com/2007/04/pattern-matching-with-ruby.html, I am wondering what it would take for Ruby to implement Erlang-like features:

-spawn, send and receive primitives
-massive processes creation
-... (all the stuff I unfortunately don't know yet, until I will lay my hands on the upcoming Joe Armstrong's Erlang book :wink: )

I am certainly not saying that Erlang should be fully brought to Ruby, but I would really like to hear the opinion of somebody who is knowledgeable in both about this idea. This would help me better understand the fundamental differences between the 2 languages.

This could also result in a mini-framework that could help in programming some concurrent systems. For instance, it looks like Kamaelia (http://kamaelia.sourceforge.net/Introduction) is trying to bring some kind of messaging model to Python. Would that be interesting to do the same for Ruby?

Eric.

路路路

---------------------------------------------------------------------------------------
Eric TORREBORRE
tel: +81 (0)90 5580 3280
e-mail: etorreborre@yahoo.com / etorreborre@docomo.ne.jp
blog: http://etorreborre.blogspot.com
---------------------------------------------------------------------------------------

___________________________________________________________________________
D茅couvrez une nouvelle fa莽on d'obtenir des r茅ponses 脿 toutes vos questions !
Profitez des connaissances, des opinions et des exp茅riences des internautes sur Yahoo! Questions/R茅ponses
http://fr.answers.yahoo.com

2

I have yet to actually mess with Erlang (I definitely plan to), but doing
what you're asking seems like an almost monumental waste of time. The reason
Erlang works the way it does is because it was built from the ground up to
support massively parallel processing. Ruby was built from the ground up as
your normal single-threaded (with support for green-threads) dynamic
programming language.

So it seems that what you're asking is to rewrite Erlang to work with Ruby
syntax; this is not something that can be patched into the Ruby VM.

Jason

路路路

On 4/18/07, Eric Torreborre <etorreborre@yahoo.com> wrote:

Hi,

After writing this post on the possibilities to add some features from
other languages to Ruby:
A++ [Eric Torreborre's Blog]: Pattern matching with Ruby, I
am wondering what it would take for Ruby to implement Erlang-like features:

-spawn, send and receive primitives
-massive processes creation
-... (all the stuff I unfortunately don't know yet, until I will lay my
hands on the upcoming Joe Armstrong's Erlang book :wink: )

I am certainly not saying that Erlang should be fully brought to Ruby, but
I would really like to hear the opinion of somebody who is knowledgeable in
both about this idea. This would help me better understand the fundamental
differences between the 2 languages.

This could also result in a mini-framework that could help in programming
some concurrent systems. For instance, it looks like Kamaelia (
http://kamaelia.sourceforge.net/Introduction\) is trying to bring some kind
of messaging model to Python. Would that be interesting to do the same for
Ruby?

Eric.

---------------------------------------------------------------------------------------
Eric TORREBORRE
tel: +81 (0)90 5580 3280
e-mail: etorreborre@yahoo.com / etorreborre@docomo.ne.jp
blog: http://etorreborre.blogspot.com

---------------------------------------------------------------------------------------

___________________________________________________________________________
D茅couvrez une nouvelle fa莽on d'obtenir des r茅ponses 脿 toutes vos questions
!
Profitez des connaissances, des opinions et des exp茅riences des
internautes sur Yahoo! Questions/R茅ponses
http://fr.answers.yahoo.com

3

Jason Roelofs wrote:

I have yet to actually mess with Erlang (I definitely plan to), but doing
what you're asking seems like an almost monumental waste of time. The reason
Erlang works the way it does is because it was built from the ground up to
support massively parallel processing. Ruby was built from the ground up as
your normal single-threaded (with support for green-threads) dynamic
programming language.

So it seems that what you're asking is to rewrite Erlang to work with Ruby
syntax; this is not something that can be patched into the Ruby VM.

Jason

Well ... maybe. I think the original poster is asking for the Ruby VM/inner interpreter to be extended with some core semantics taken from Erlang. I think it *can* be done, but the question is *should* it be done? My own personal belief is that it should. At the very least, the Ruby VM should make available all of the OS concurrency primitives supported by Linux, MacOS, Solaris and Windows as efficiently as possible. dRB and threads aren't going away, but there are many other ways to do concurrent programming sensibly.

That said, one of the other things that adding concurrency does to a language, any language, is to force its community to think harder about correctness issues. The Erlang community has put a lot of thought into this, given that their target market is communications systems that must work when entire cities lose electrical power, etc. They have correctness-checking tools, and syntactic and semantic constructs in the language to support these tools. The attitude I see expressed in the Ruby community is "testing conquers all". That's clearly insufficient, since testing can only show the presence of bugs and not the absence of them. :slight_smile:

So yes, it's a good idea. But if you need Erlang now, use Erlang now.

路路路

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.net/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

4

I'm not sure that Erlang is the right place to be looking for good Ruby concurrency models, given the fundamental differences between the two languages. What I think would be interesting though is if some of the CSP and Pi-Calculus inspired stuff that's being worked on by the KRoC team (http://www.cs.kent.ac.uk/projects/ofa/kroc/\) make it into the Ruby world.

Ellie

Eleanor McHugh
Games With Brains

路路路

On 18 Apr 2007, at 14:01, Jason Roelofs wrote:

I have yet to actually mess with Erlang (I definitely plan to), but doing
what you're asking seems like an almost monumental waste of time. The reason
Erlang works the way it does is because it was built from the ground up to
support massively parallel processing. Ruby was built from the ground up as
your normal single-threaded (with support for green-threads) dynamic
programming language.

So it seems that what you're asking is to rewrite Erlang to work with Ruby
syntax; this is not something that can be patched into the Ruby VM.

----
raise ArgumentError unless @reality.responds_to? :reason

5

Hi,

路路路

In message "Re: Could Ruby be a good Erlang-like?" on Wed, 18 Apr 2007 22:36:20 +0900, "M. Edward (Ed) Borasky" <znmeb@cesmail.net> writes:

So yes, it's a good idea. But if you need Erlang now, use Erlang now.

Agreed. It might be a subject for the research project. For your
information, here's the Erlang-like Scheme. <http://toute.ca/&gt;

              matz.

6

Eleanor McHugh wrote:

路路路

On 18 Apr 2007, at 14:01, Jason Roelofs wrote:

I have yet to actually mess with Erlang (I definitely plan to), but doing
what you're asking seems like an almost monumental waste of time. The reason
Erlang works the way it does is because it was built from the ground up to
support massively parallel processing. Ruby was built from the ground up as
your normal single-threaded (with support for green-threads) dynamic
programming language.

So it seems that what you're asking is to rewrite Erlang to work with Ruby
syntax; this is not something that can be patched into the Ruby VM.

I'm not sure that Erlang is the right place to be looking for good Ruby concurrency models, given the fundamental differences between the two languages. What I think would be interesting though is if some of the CSP and Pi-Calculus inspired stuff that's being worked on by the KRoC team (http://www.cs.kent.ac.uk/projects/ofa/kroc/\) make it into the Ruby world.

Uh ... I'll go check it out, but don't get me started on Pi-Calculus vs. Petri Nets in the Business Process Modeling arena. :slight_smile: Suffice it to say I've been studying Petri nets for something like 20 years now and I find Pi-Calculus and CSP (and related process algebra notations) dang near impossible to read as a result.

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.net/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

7

Yukihiro Matsumoto wrote:

Hi,

>So yes, it's a good idea. But if you need Erlang now, use Erlang now.

Agreed. It might be a subject for the research project. For your
information, here's the Erlang-like Scheme. <http://toute.ca/&gt;

              matz.

That's Termite, right? The Gambit Scheme add-on? Quite frankly, I think they did a better job than Erlang. :slight_smile: Sockets aren't going away. System V IPC isn't going away. Threads aren't going away. dRB and Rinda aren't going away. Monitors aren't going away. And I don't see the need to re-invent the OS in every language -- just the parts Windows got wrong. :slight_smile:

路路路

In message "Re: Could Ruby be a good Erlang-like?" > on Wed, 18 Apr 2007 22:36:20 +0900, "M. Edward (Ed) Borasky" <znmeb@cesmail.net> writes:

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.net/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

8

Well I can't say I like the maths notations much - reminds me too much of studying control theory back in the 80s and wondering why my lecturer was so excited about what amounts to little more than plumbing diagrams. It's so ironic that I ended up working in embedded control systems...

I think possibly I'm more attracted to the Occam-pi language structures as I can sense ways in which they can be implemented using Ruby's threads or dRb/Rinda and multiple processes.

Ellie

Eleanor McHugh
Games With Brains

路路路

On 19 Apr 2007, at 04:51, M. Edward (Ed) Borasky wrote:

Eleanor McHugh wrote:

I'm not sure that Erlang is the right place to be looking for good Ruby concurrency models, given the fundamental differences between the two languages. What I think would be interesting though is if some of the CSP and Pi-Calculus inspired stuff that's being worked on by the KRoC team (http://www.cs.kent.ac.uk/projects/ofa/kroc/\) make it into the Ruby world.

Uh ... I'll go check it out, but don't get me started on Pi-Calculus vs. Petri Nets in the Business Process Modeling arena. :slight_smile: Suffice it to say I've been studying Petri nets for something like 20 years now and I find Pi-Calculus and CSP (and related process algebra notations) dang near impossible to read as a result.

----
raise ArgumentError unless @reality.responds_to? :reason

9

"M. Edward (Ed) Borasky" <znmeb@cesmail.net> writes:

I'm not sure that Erlang is the right place to be looking for good
Ruby concurrency models, given the fundamental differences between
the two languages. What I think would be interesting though is if
some of the CSP and Pi-Calculus inspired stuff that's being worked
on by the KRoC team (http://www.cs.kent.ac.uk/projects/ofa/kroc/\)
make it into the Ruby world.

Uh ... I'll go check it out, but don't get me started on Pi-Calculus
vs. Petri Nets in the Business Process Modeling arena. :slight_smile: Suffice it
to say I've been studying Petri nets for something like 20 years now
and I find Pi-Calculus and CSP (and related process algebra notations)
dang near impossible to read as a result.

What about the Join calculus? It always seemed to me to be relatively
easy to program and implement, while still being powerful enough for
serious use, but then I never wrote real code in it.

路路路

M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

10

Eleanor McHugh wrote:

Eleanor McHugh wrote:

I'm not sure that Erlang is the right place to be looking for good Ruby concurrency models, given the fundamental differences between the two languages. What I think would be interesting though is if some of the CSP and Pi-Calculus inspired stuff that's being worked on by the KRoC team (http://www.cs.kent.ac.uk/projects/ofa/kroc/\) make it into the Ruby world.

Uh ... I'll go check it out, but don't get me started on Pi-Calculus vs. Petri Nets in the Business Process Modeling arena. :slight_smile: Suffice it to say I've been studying Petri nets for something like 20 years now and I find Pi-Calculus and CSP (and related process algebra notations) dang near impossible to read as a result.

Well I can't say I like the maths notations much - reminds me too much of studying control theory back in the 80s and wondering why my lecturer was so excited about what amounts to little more than plumbing diagrams. It's so ironic that I ended up working in embedded control systems...

I think possibly I'm more attracted to the Occam-pi language structures as I can sense ways in which they can be implemented using Ruby's threads or dRb/Rinda and multiple processes.

I took a cruise by the web site and I must say it was interesting but I have a very bad taste in my mouth from Occam. I used to work for a company called Floating Point Systems. A bunch of very bright folks bet a big chunk of the company on the Transputer and Occam. It was a classic case of a beautiful theory being murdered by a gang of brutal facts. There were less than a handful of Occam programmers in the world. Our marketplace consisted of FORTRAN, C, and to a certain extent Pascal programmers.

To be blunt, Erlang is a production-ready, commercially supported industrial strength programming environment -- no, let me make that stronger -- *software engineering environment* with a lot of momentum and a strong open-source community. Occam, CSP, the Pi-Calculus and Pi-Occam aren't. Aside from the obvious entrenched position of the Pi-Calculus in business process modeling, I don't see much other than another beautiful theory walking alone on a dark and stormy night in a very bad neighborhood. :slight_smile:

For a more positive spin on the subject, for those interested in the "obvious entrenched position" I mentioned above, see _Essential Business Process Modeling_ by Michael Harvey. Anybody who implements business applications, in Ruby or otherwise, should have a firm grasp of the contents thereof.

路路路

On 19 Apr 2007, at 04:51, M. Edward (Ed) Borasky wrote:

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.net/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

11

Christian Neukirchen wrote:

"M. Edward (Ed) Borasky" <znmeb@cesmail.net> writes:

I'm not sure that Erlang is the right place to be looking for good
Ruby concurrency models, given the fundamental differences between
the two languages. What I think would be interesting though is if
some of the CSP and Pi-Calculus inspired stuff that's being worked
on by the KRoC team (http://www.cs.kent.ac.uk/projects/ofa/kroc/\)
make it into the Ruby world.
      

Uh ... I'll go check it out, but don't get me started on Pi-Calculus
vs. Petri Nets in the Business Process Modeling arena. :slight_smile: Suffice it
to say I've been studying Petri nets for something like 20 years now
and I find Pi-Calculus and CSP (and related process algebra notations)
dang near impossible to read as a result.
    
What about the Join calculus? It always seemed to me to be relatively
easy to program and implement, while still being powerful enough for
serious use, but then I never wrote real code in it.

I'm not familiar with it. My "introduction" to concurrent programming was via Per Brinch Hansen's "Concurrent Pascal" and "Edison" programming languages, which were built on the concept of "monitors". Monitors exist in Ruby, so that's a no-brainer. I also did some small concurrent programming projects in a dialect of Linda called "Circl" in the early 1990s. Ruby has Rinda; again a no-brainer.

I haven't done much with threads or other low-level techniques -- I much prefer having "industrial strength tools" available for the difficult tasks of concurrent programming. I like to be able to prove, for example, that my code cannot deadlock. And I like to be able to estimate how long it's going to take me to get an answer.

路路路

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.net/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

12

Eleanor McHugh wrote:

I think possibly I'm more attracted to the Occam-pi language structures as I can sense ways in which they can be implemented using Ruby's threads or dRb/Rinda and multiple processes.

I took a cruise by the web site and I must say it was interesting but I have a very bad taste in my mouth from Occam. I used to work for a company called Floating Point Systems. A bunch of very bright folks bet a big chunk of the company on the Transputer and Occam. It was a classic case of a beautiful theory being murdered by a gang of brutal facts. There were less than a handful of Occam programmers in the world. Our marketplace consisted of FORTRAN, C, and to a certain extent Pascal programmers.

My experiments were limited by minimal access to hardware. My supervisor had a Meiko Transputer Surface but that was mainly used for large-scale skeletal forces simulations so I never got to play, and anyway Occam in its version 1 form is an ugly dog. The transputer architecture though fascinated me and I still have an assembly language manual for it lurking somewhere on my bookshelf.

To be blunt, Erlang is a production-ready, commercially supported industrial strength programming environment -- no, let me make that stronger -- *software engineering environment* with a lot of momentum and a strong open-source community. Occam, CSP, the Pi-Calculus and Pi-Occam aren't. Aside from the obvious entrenched position of the Pi-Calculus in business process modeling, I don't see much other than another beautiful theory walking alone on a dark and stormy night in a very bad neighborhood. :slight_smile:

I've yet to meet any theory that comfortably withstood the light of day, so I won't hold that against it :wink: I can definitely see the argument for using Erlang in preference to Occam, but I don't think that invalidates the value of lifting its core strengths (concurrency and code mobility) for use in Ruby. If they are good abstractions then Ruby will make them much easier to use, and if not it will soon show up their faults lol

Ellie

Eleanor McHugh
Games With Brains

路路路

On 19 Apr 2007, at 15:23, M. Edward (Ed) Borasky wrote:
----
raise ArgumentError unless @reality.responds_to? :reason

13

M. Edward (Ed) Borasky wrote:

Aside from the obvious entrenched position of the Pi-Calculus in business process modeling, I don't see much other than another beautiful theory walking alone on a dark and stormy night in a very bad neighborhood. :slight_smile:

Ed, have you seem the YAWL workflow engine from Queensland
University of Technology and the DSTC? It's formally based
on Petri nets. I had a play with it a while back, but didn't
see it as mature (read, overburdened with pre-canned features)
to easily make use of in a commercial environment (which was
my interest). Granted that you might be using Petri nets
mainly for things other than business workflow automation,
but I'd like your opinion on the chance YAWL might have to
change things in the BPML space.

For a more positive spin on the subject, for those interested in the "obvious entrenched position" I mentioned above, see _Essential Business Process Modeling_ by Michael Harvey. Anybody who implements business applications, in Ruby or otherwise, should have a firm grasp of the contents thereof.

Thanks for the recommendation. I was needing a good pointer like
that.

My interest in business process is where I see it tying in with
fact-based information modeling. It would seem a shame to mix a
revolutionary yet well-founded technique like Object Role Modeling
with the abortion that is BPML, when it could instead be mixed
with a similarly foundational technology based on Petri nets.

Clifford Heath.

14

Clifford Heath wrote:

M. Edward (Ed) Borasky wrote:

Aside from the obvious entrenched position of the Pi-Calculus in business process modeling, I don't see much other than another beautiful theory walking alone on a dark and stormy night in a very bad neighborhood. :slight_smile:

Ed, have you seem the YAWL workflow engine from Queensland
University of Technology and the DSTC? It's formally based
on Petri nets. I had a play with it a while back, but didn't
see it as mature (read, overburdened with pre-canned features)
to easily make use of in a commercial environment (which was
my interest). Granted that you might be using Petri nets
mainly for things other than business workflow automation,
but I'd like your opinion on the chance YAWL might have to
change things in the BPML space.

As Deep Throat said in "All The President's Men," follow the money. :slight_smile: There are two entrenched 800-pound gorillas. I've forgotten the names, but one is based on Petri nets and the other on Pi-Calculus, and some kind of "both sides win" integration of the two is emerging. I think there's virtually zero chance of something else making headway. So I suppose I'll need to learn the subset of Pi-calculus that ends up in the final mix.

My interest in business process is where I see it tying in with
fact-based information modeling. It would seem a shame to mix a
revolutionary yet well-founded technique like Object Role Modeling
with the abortion that is BPML, when it could instead be mixed
with a similarly foundational technology based on Petri nets.

Well ... to my knowledge, Pi-calculus can *directly* model "mobility", and Petri nets can't. It's been a while since I read the book, and I've lent my copy out to a co-worker who's more directly involved with business process modeling. My interest is pretty much only in computer systems performance modeling, and there (generalized) stochastic Petri nets are about the most complicated tool I need, and perhaps 99 percent of what I need to do can be handled by even simpler tools based on product form queuing networks. That's the source of my bias towards Petri nets -- they've been around a long time and predate most of the other analysis tools for dealing with concurrency. In fact, I think they predate the fundamental theorem of product form queuing networks.

路路路

Clifford Heath.

--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.net/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.