I'd also like to reiterate that Erlang is do= ing the right thing here and that silently swallowing errors in an asynchro= nous concurrent system (which is what you're proposing) is an extremely= bad idea. In an asynchronous system, the error log is your only tool for u= nderstanding what's broken and where. You will most certainly want to c= apture and log all errors, not silently ignore them, or else you will have = no visibility into if your asynchronous background tasks are working or not= .

On Thu, Jul= 5, 2012 at 5:37 PM, Tony Arcieri <tony.arcieri@gmail.com> wrote:

On Thu, Jul 5, 2012 at 12:31 PM, rex goxman <lists@ruby-forum.com= > wrote:

1. I have proposed no system. =A0I have stated that I'd like to use gre= en
threads, and asked if ruby still had them available.

<= /div>
Your suggested use case for green threads was firing off ba= ckground jobs that may or may not break, with zero interest as to if they c= omplete successfully. This is not what Erlang does. Erlang/OTP provides ext= ensive reporting of all failures of any OTP components.

At least, that seems to be what you're suggesting h= ere. Please correct me if I'm wrong:

This is a crappy example, but say you need to do some
c= alculation which might fail or even crash, but you don't want (or need)=
to check the inputs to the calculation, or wrap the thing up in= an error
catching mechanism, or anything of this nature. = =A0You just want to
calculate it, and if it works, fine, and if it doesn't (or = even crashes)
- fine, your main program continues to run.=A0=

--
Tony Arcieri