[ruby-core:85171] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid

[Eric Wong <normalperson@yhbt.net>]

danieldasilvaferreira@gmail.com wrote:
> When Koichi referring to threads functionality in ruby land writes and says: 
> 
> > "But most (many? some? a few?) of ruby programmer (including me) can not write correct code I believe."
 
> These sentences have a very big impact. 

They should not have a big impact.  Really make up your
own mind on these things instead just believing somebody;
even if they are a leader of this project.

I suspect if you look at any development archives for any major
projects; you will see similar statements from major contributors.

> The key word for me here is a clear message that could say with confidence: 
> 
> "Ruby is rock solid for async because..."

Saying something like that would open us up to lawsuits.
The following (or similar) disclaimer is in every project
I work on:

  6. THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR
     IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
     WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
     PURPOSE.

So, no, I'm never going to say anything I work on is "rock solid".

> If we don't succeed to pass this message to the world of
> programming ruby will slowly be replaced by other languages.

In my experience, people left Ruby because incompatibilities got
painful and memory usage was too high.

Ruby 1.8 green Threads were a middle ground.  Since 1.9+, Fibers
went in one direction (harder-to-use), while native Threads
went in another direction (too heavy); and there's nothing left
in the middle.

All I aim to do with this feature is fill the void in the middle.

> Parallelism and concurrency and async will be everywhere in the future.

They already are, and have been for a while.

> We need to create the foundations for a post ruby 3 future in
> ruby land where async is the standard for the many and not the
> exception for the few.

Internal implementation can be async, but the public API will
likely remain and favor synchronous (because redesiging existing
libs is expensive).

New features should always be opt-in, never a requirement.
That said, it should still be easy to port code over to take
advantage of new features; so I want to minimize publically
visible changes.