[jupp0r]

The API looks nice on the surface, but this will be expensive to operate due to Ruby and Rails’ lack of support for concurrency. Everything is blocking, which is not a great match for the async nature of interacting with these models.

[igravious]

https://ruby-concurrency.github.io/concurrent-ruby/1.1.5/Con...

https://thoughtbot.com/blog/my-adventure-with-async-ruby

First two hits on Google.

[jupp0r]

Well instead of looking at the two first hits of Google I spent several years on a platform team of a multi billion dollar company using mostly Rails and worked on solving real world problems caused by Ruby/Rails’ design choices which lead me to believe that Ruby concurrency as of today is hot garbage.

They need fundamental breaking changes to the language to fix this, which means people won’t be able to use their beloved pile of 438 gems that haven’t seen a commit in 7 years. If I had to bet, I’d say the language is dead. It might still be a nice niche language for easy prototyping, but the world has moved on to async/await (js/python/Rust/C++) or stackful coroutines (Go).

[RangerScience]

Ruby isn't dead and like all alive things, it grows and changes; your expectation is out of date.

https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-rele...

[jupp0r]

Unfortunately, 5 years after the release you linked, almost none of this has made it to Rails or even to relatively new libraries this post is about. The reason (imho) are unfortunate design choices in how the language incorporates concurrency - it’s just not well done.