From: Eric Wong Date: 2018-01-28T10:47:38+00:00 Subject: [ruby-core:85171] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid 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. Unsubscribe: