Could Ruby be a good Erlang-like?

Discussion in 'Ruby' started by Eric Torreborre, Apr 18, 2007.

  1. Hi,=0A=0AAfter writing this post on the possibilities to add some features =
    from other languages to Ruby:
    rn-matching-with-ruby.html, I am wondering what it would take for Ruby to i=
    mplement Erlang-like features:=0A=0A-spawn, send and receive primitives=0A-=
    massive processes creation=0A-... (all the stuff I unfortunately don't know=
    yet, until I will lay my hands on the upcoming Joe Armstrong's Erlang book=
    ;-) )=0A=0AI am certainly not saying that Erlang should be fully brought t=
    o Ruby, but I would really like to hear the opinion of somebody who is know=
    ledgeable in both about this idea. This would help me better understand the=
    fundamental differences between the 2 languages.=0A=0AThis could also resu=
    lt in a mini-framework that could help in programming some concurrent syste=
    ms. For instance, it looks like Kamaelia (
    ntroduction) is trying to bring some kind of messaging model to Python. Wou=
    ld that be interesting to do the same for Ruby?=0A=0AEric.=0A=0A-----------=
    -=0AEric TORREBORRE=0Atel: +81 (0)90 5580 3280=0Ae-mail: [email protected]=
    com / =0Ablog:
    ----------=0A=0A=0A=0A=0A=0A=0A =0A___________________________________=
    ________________________________________ =0AD=E9couvrez une nouvelle fa=E7o=
    n d'obtenir des r=E9ponses =E0 toutes vos questions ! =0AProfitez des conna=
    issances, des opinions et des exp=E9riences des internautes sur Yahoo! Ques=
    tions/R=E9ponses =0A
    Eric Torreborre, Apr 18, 2007
    1. Advertisements

  2. 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. :)

    So yes, it's a good idea. But if you need Erlang now, use Erlang now.
    M. Edward (Ed) Borasky, Apr 18, 2007
    1. Advertisements

  3. 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 ( make
    it into the Ruby world.


    Eleanor McHugh
    Games With Brains
    Eleanor McHugh, Apr 18, 2007
  4. 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. :) 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, Apr 19, 2007
  5. 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.


    Eleanor McHugh
    Games With Brains
    Eleanor McHugh, Apr 19, 2007
  6. 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

    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. :)

    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.
    M. Edward (Ed) Borasky, Apr 19, 2007
  7. 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.
    I've yet to meet any theory that comfortably withstood the light of
    day, so I won't hold that against it ;) 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


    Eleanor McHugh
    Games With Brains
    Eleanor McHugh, Apr 19, 2007
  8. 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.
    Thanks for the recommendation. I was needing a good pointer like

    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.
    Clifford Heath, Apr 20, 2007
  9. As Deep Throat said in "All The President's Men," follow the money. :)
    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.
    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.
    M. Edward (Ed) Borasky, Apr 20, 2007
  10. 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, Apr 20, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.