From: David Masover Date: 2009-12-09T06:57:29+09:00 Subject: Re: how about ruby's threads? On Tuesday 08 December 2009 02:27:31 pm Brian Candler wrote: > Tony Arcieri wrote: > > On Tue, Dec 8, 2009 at 2:46 AM, Brian Candler > > > > wrote: > >> When I get a few spare cycles I'm trying to hack together a > >> ruby-flavoured erlang: just a front end which emits either the erlang > >> abstract syntax form, or regular erlang source. > > > > For what it's worth, that's what Reia is already. > > Reia will run on the Erlang VM but will be a > substantially different language to Erlang: it will have destructive > assignment, and be a lot more dynamic. Being able to compile AOT to > .beam files is not necessarily going to be provided. Furthermore it will > have different function call semantics, For what it's worth, just about all of these sound like improvements to me. The "destructive assignment" seems to come in two forms -- private variables can be destructively assigned, but that's a purely syntactical treatment, as those will (I assume) be compiled into singly-assigned Erlang variables. Instance variables can also be destructively assigned, and that's the biggest difference. But they also cannot be shared between processes (that I know of), so they don't break the advantages of Erlang. > What I'm toying with is just a different syntax for standard Erlang, > which you'd compile to .beam and would be indistinguishable from Erlang > at that level. I should clarify, then -- while I complain about Erlang's syntax, that's not the only problem I have with it. I _like_ object-oriented semantics, and I think they'd map well onto actors, which is exactly the approach Reia is taking. Think about the features that make Ruby shine. A few of those are purely syntactical. A few of them are based on the core idea that objects don't have to inherently be any particular type -- they're just entities you send messages to, and you don't know what response you'll get until you actually send the message. This is both the core of duck typing and a fair description of Erlang processes. Essentially, an Erlang function that expects a process doesn't care what kind of process you give it, so long as that process can handle the messages it wants to send. So while I can see the usefulness of pattern-matching for handling incoming requests, that's a bit like method_missing -- or maybe the opposite, putting something in front of the method calls. Still, most messages make sense mapping directly to method calls, and I think doing so would work well as a convention-over-configuration approach -- for the same reason that it makes sense to have URLs correspond to methods on a controller, by convention. I guess what I'm saying is, I want to have my cake and eat it. Ruby is already built in such a way that it would map very naturally onto the actor model. Unfortunately, since that's never been tried, any attempt to do so is probably doomed -- there are entirely too many assumptions that code is executed linearly. I'm actually trying anyway, for fun. I've been (on and off for about a year) writing an actor library for Ruby that actually does exactly what I'm describing. But it will be slow (it uses Threads and Queues) and only safe if you know what you're doing.