News for hackers. Stuff that matters.
Re:Why Wasn't Ruby 3 Faster? by strken on Thursday February 11, 2021 @12:35AM (#26098583)
We were "IO-bound" using a setup that executed a maximum of two requests at a time, completely blocked processing new requests until earlier ones fully completed, and took a long time to execute requests because of unexpected latency in a dependency, while 20 frustrated users sat in a room hammering the refresh button and dumping more tasks onto the queue.

You're absolutely right when you say there was something seriously wrong with the setup! The problem is that it was more or less what you'd get if you set up a default Rails app behind Passenger, and Passenger did this because some of the major Ruby gems weren't threadsafe (e.g. Rails, until 2008), which comes back to concurrency problems with the ecosystem.

Re:Why Wasn't Ruby 3 Faster? by jacobsenscott on Thursday February 11, 2021 @01:39AM (#26098901)
If you were IO bound you could have run many more rails processes. There's no reason to limit your self to one process per core. You can run many times that number of processes since they are all just waiting on IO.
Re:Why Wasn't Ruby 3 Faster? by EdwardDiego on Thursday February 11, 2021 @04:32AM (#26099757)
I'm sure the original commenter is loving all your 20/20 hindsight.
Re:Why Wasn't Ruby 3 Faster? by coldtea on Thursday February 11, 2021 @05:33AM (#26100087)
The original commenter offered his story as an issue with Ruby preventing X.

The 20/20 hindsight is not meant to retroactively solve their problem, it's mean as a counter-argument, that the problem was their design, not Ruby.

Re:Why Wasn't Ruby 3 Faster? by Person5478 on Thursday February 11, 2021 @08:30AM (#26101256)
The posters point is that Ruby has surprising concurrency semantics compared to other solutions.
Re:Why Wasn't Ruby 3 Faster? by Evan__ on Thursday February 11, 2021 @09:47AM (#26101965)
It has the same concurrency semantics w/r/t IO as any other language that isn't using an event based runtime. If you wrote your app in C and used a single thread you'd have the exact same issue.
Re:Why Wasn't Ruby 3 Faster? by kevincox on Thursday February 11, 2021 @08:46AM (#26101428)
Ruby should be able to execute more than one request on a time because while it can only have one thread executing Ruby at a time it can run other threads while waiting for IO. It seems like for some reason Rails was limited to one thread which is not how it should be configured.
Re:Why Wasn't Ruby 3 Faster? by darwinwhy on Thursday February 11, 2021 @12:46AM (#26098636)
What is Passenger exactly? Never heard of it before now. A quick Google brings up a marketing page that doesn't explain much more.
Re:Why Wasn't Ruby 3 Faster? by ForHackernews on Thursday February 11, 2021 @03:49AM (#26099556)
It's an application server. If you're familiar with the Python webdev ecosystem, Passenger is roughly a Ruby equivalent for something like uWSGI or Gunicorn. (IIRC, you can actually run Python apps with Passenger now, too)
Re:Why Wasn't Ruby 3 Faster? by coldtea on Thursday February 11, 2021 @05:34AM (#26100091)
Where now = for 5 years or more.
Re:Why Wasn't Ruby 3 Faster? by universa1 on Thursday February 11, 2021 @03:08AM (#26099334)
Something like mod_perl / mod_xxx in the early days... and they did some work on the concurrency problems with rails and ruby around the ruby 1.8 days iirc... In the meantime they expanded to more languages...
Re:Why Wasn't Ruby 3 Faster? by e12e on Thursday February 11, 2021 @08:55AM (#26101510)
Not sure if you mean this page or not: https://www.phusionpassenger.com/ But as they say, it's an application server. Similar to mod_perl for apache/php, unicorn or indeed nodejs (which can function as an application server for Javascript).
Re:Why Wasn't Ruby 3 Faster? by johnmcauley on Thursday February 11, 2021 @01:18AM (#26098791)
It’s a Ruby web server that can we bed used with nginx or Apache.