# Book wanted: Concurrent Ruby Programming (was Re: Book wante **URL:** \ **Category:** Ruby\ **Created:** [November 7, 2006, 4:36pm UTC](https://www.ruby-forum.com/t/book-wanted-concurrent-ruby-programming-was-re-book-wante/75105 "2006-11-07T16:36:16Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![MSEdward\_SEdS\_Bora](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7bcc69/32.png) [@MSEdward\_SEdS\_Bora](https://www.ruby-forum.com/u/MSEdward_SEdS_Bora)\ **Post date:** [November 7, 2006, 4:36pm UTC](https://www.ruby-forum.com/t/book-wanted-concurrent-ruby-programming-was-re-book-wante/75105/1 "2006-11-07T16:36:16Z")
Ola B. wrote: > > > [Ruby Wish List](http://kleb.tadalist.com/lists/public/427170) > > > resident expert, I think … > > But concurrency in Ruby is still green threads, so that would have to > be either concurrency with YARV, or concurrency with separate Ruby > processes communicating in some way. > That was actually my purpose in making the suggestion … to stimulate > debate about concurrency in Ruby, the major differences between the > current 1.8 and proposed 1.9/2.0 concurrency tools, the way other > languages deal, successfully or unsuccessfully, with concurrency, etc., > etc., etc. 🙂 I think Erlang is the horse to challenge in this race, or perhaps, on a more theoretical note, the Pi-calculus. And right now, EventMachine appears to be Ruby’s horse in the race, which is why I suggested that Francis write the book. 🙂 On a related note, some Scheme folks have implemented “Erlang-like” lightweight processes. Here’s a link to the paper; I’ve got the software installed but haven’t had a chance to experiment with it. [http://scheme2006.cs.uchicago.edu/09-germain.pdf](http://scheme2006.cs.uchicago.edu/09-germain.pdf) ---
**Author:** ![MSEdward\_SEdS\_Bora](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7bcc69/32.png) [@MSEdward\_SEdS\_Bora](https://www.ruby-forum.com/u/MSEdward_SEdS_Bora)\ **Post date:** [November 7, 2006, 7:55pm UTC](https://www.ruby-forum.com/t/book-wanted-concurrent-ruby-programming-was-re-book-wante/75105/2 "2006-11-07T19:55:43Z")
M. Edward (Ed) Borasky wrote: > On a related note, some Scheme folks have implemented “Erlang-like” > lightweight processes. Here’s a link to the paper; I’ve got the software > installed but haven’t had a chance to experiment with it. Gambit Scheme is wicked. Incredibly cool. Lisp + Erlangs concurrency features. Great. If “easier” syntax is needed, Scala has some very interesting parts too. – Ola B. ([http://ola-bini.blogspot.com](http://ola-bini.blogspot.com)) JvYAML, RbYAML, JRuby and Jatha contributor System Developer, Karolinska Institutet ([http://www.ki.se](http://www.ki.se)) OLogix Consulting ([http://www.ologix.com](http://www.ologix.com)) “Yields falsehood when quined” yields falsehood when quined. ---
**Author:** ![MSEdward\_SEdS\_Bora](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7bcc69/32.png) [@MSEdward\_SEdS\_Bora](https://www.ruby-forum.com/u/MSEdward_SEdS_Bora)\ **Post date:** [November 8, 2006, 4:07am UTC](https://www.ruby-forum.com/t/book-wanted-concurrent-ruby-programming-was-re-book-wante/75105/3 "2006-11-08T04:07:29Z")
Ola B. wrote: > M. Edward (Ed) Borasky wrote: > > > On a related note, some Scheme folks have implemented “Erlang-like” > > lightweight processes. Here’s a link to the paper; I’ve got the software > > installed but haven’t had a chance to experiment with it. > > Gambit Scheme is wicked. Incredibly cool. Lisp + Erlangs concurrency > features. Great. > > If “easier” syntax is needed, Scala has some very interesting parts too. > The latest version of “Termite” isn’t in the latest beta of Gambit > Scheme – you need to download it separately. But it _is_ cool. ---
**Author:** ![MSEdward\_SEdS\_Bora](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7bcc69/32.png) [@MSEdward\_SEdS\_Bora](https://www.ruby-forum.com/u/MSEdward_SEdS_Bora)\ **Post date:** [November 8, 2006, 12:56pm UTC](https://www.ruby-forum.com/t/book-wanted-concurrent-ruby-programming-was-re-book-wante/75105/4 "2006-11-08T12:56:48Z")
On 7 Nov 2006, at 15:34, M. Edward (Ed) Borasky wrote: > That was actually my purpose in making the suggestion … to stimulate > debate about concurrency in Ruby, the major differences between the > current 1.8 and proposed 1.9/2.0 concurrency tools, the way other > languages deal, successfully or unsuccessfully, with concurrency, > etc., > etc., etc. 🙂 I read this a while ago - I have a feeling the link came from this list so you might be aware of it already. [http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html](http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html) Ashley ---
**Author:** ![MSEdward\_SEdS\_Bora](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7bcc69/32.png) [@MSEdward\_SEdS\_Bora](https://www.ruby-forum.com/u/MSEdward_SEdS_Bora)\ **Post date:** [November 8, 2006, 4:29pm UTC](https://www.ruby-forum.com/t/book-wanted-concurrent-ruby-programming-was-re-book-wante/75105/5 "2006-11-08T16:29:35Z")
Ashley M. wrote: > I read this a while ago - I have a feeling the link came from this > list so you might be aware of it already. > > [The Problem with Threads | EECS at UC Berkeley](http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html) > > Ashley > Yes … there was some discussion a while back on that. Despite the fact > that threads have their problems, they aren’t going away. Neither are > sockets, lightweight processes, System V IPC, Linda/Rinda, CSP, CCS, the > Pi calculus, Petri nets, mutexes, monitors, the ACID properties for > database transactions, multi-core processors, or any of the other > reasons why a programming language needs to support concurrency and > tools for that support. Some of these may die out, of course, through the natural competitive process. For example, I hadn’t heard much about the Linda approach until Ruby “re-discovered” it. There’s a “raging battle” in the business processing modeling world between Petri nets and the Pi calculus, and as a result both are fairly well supported and will be around for a while. And I haven’t heard a lot recently about System V IPC; apparently Linus Torvalds doesn’t like the constructs, so they were grudgingly put into the Linux kernel for the same reason people that have issues with threads implement them anyhow. I have my personal favorites, of course. I’m a big fan of lightweight processes as implemented in Erlang and Gambit Scheme/Termite. I’m a big fan of Petri nets because they carry along with them not only mechanisms for analysis of concurrent program correctness but also performance and other timing-related factors. I expect the theoreticians will eventually get around to providing the same performance modeling constructs in the Pi calculus, but I haven’t seen anything yet.