Ruby's thread more "functional" than OCaml's

I'm relaxing some of mine [[!initial bad impressions on Ruby|first_thoughts_on_ruby]]. This is mainly due to the fact that the Ruby book I ordered on Amazon finally arrived (after a lost shipment, the first of my whole customer story with Amazon, happily they refunded me completely).

In the book I managed to find a rigorous (though not formal as I would have liked) description of Ruby's semantics and even some snippets of the grammar of the language (Rant: how the heck is possible that a modern language like Ruby lacks a complete description of its grammar????). Anyhow, now I'm feeling more comfortable with the language and I'm starting to put in the right setting some of what I believed to be its rough edges.

Today, playing with Ruby's threads, I discovered a function in Ruby's Thread API that I can't help noticing is "more functional" than corresponding features in the Thread API of my beloved OCaml. Using Thread#value indeed the value returned by the last statement executed in a given thread can be retrieved (note that in Ruby every statement returns a value: yet another functional pearl). It's like a Thread#join on steroids.

In OCaml the only way (that comes into my mind) to do the same is establishing a (typed) channel among the thread creator and the created thread, sending a return value from the thread, and having the creator block on the matching receive. Or (please don't) ... you can use a global variable ...

Neat Ruby threads.

To balance this, according to my first read of Ruby's threading capability, it's my impression that not only at most one thread can execute Ruby code at a time (limitation shared by OCaml, due to the non-distributed nature of mark and sweep garbage collectors), but also a thread blocked on a syscall will block all other threads to run.

Dumb Ruby threads (but I still hope I'm wrong ...)