4 ms·

Pick an ARCHITECTURE that make simple to do things in parallel. People are saying that python and ruby can't do things in parallel in an easy way. While techn

by siscia 6y ago

Pick an ARCHITECTURE that make simple to do things in parallel. People are saying that python and ruby can't do things in parallel in an easy way. While technically true, it is also pretty much irrelevant, since we have multithreading.

t-writescode 6y ago
It's very relevant if the external webservice calls take long enough. Multithreading just increases your technical max concurrent request up to the size of your multithreading maximum. Async lets the computer do _anything else_ while it's waiting for the request. If you're handling thousands of concurrent requests, you need thousands of threads available ... or, 10s or hundreds of threads with async available (your mileage may vary).
speedgoose 6y ago
I think it's relevant. Let's say you write an API that only needs to call another API that takes 1 second to respond. A golang or nodejs server would have no problem to serve thousands of parallel requests. You can't really justify having 5000 ruby threads, they are heavy and they will use too much memory.
- Lio 6y ago
  If you wanted to run 5000 parallel async requests in MRI ruby surely you'd just use a simple thread pool wouldn't you? If you prefer some other paradigm then Concurrent Ruby[1] has a swiss army knife of them including event loops and Go style SCP. I think things will improve in ruby 3 but even without ractors it's still possible to do either async IO in MRI or use JRuby for fully parallel ruby. 1. https://github.com/ruby-concurrency/concurrent-ruby https://github.com/ruby-concurrency/concurrent-ruby
  - speedgoose 6y ago
    It's good to see that Ruby is getting some async IO. Hopefully Rails and the other frameworks will use it.
    - Lio 6y ago
      This is not really a new thing but maybe it's not well known. Ruby's had aysnc IO support for at at least 10 years I think. Rails itself has been using Concurrent Ruby since at least Rails 5 but I think it had its own concurrency patterns even before that. e.g. ActiveRecord database drivers. Jesse Storimer's Working with Ruby Threads book from 2013 is still a really good resource for concurrency in ruby.

by siscia 6y ago

t-writescode 6y ago

It's very relevant if the external webservice calls take long enough. Multithreading just increases your technical max concurrent request up to the size of your multithreading maximum. Async lets the computer do _anything else_ while it's waiting for the request. If you're handling thousands of concurrent requests, you need thousands of threads available ... or, 10s or hundreds of threads with async available (your mileage may vary).

speedgoose 6y ago

I think it's relevant. Let's say you write an API that only needs to call another API that takes 1 second to respond. A golang or nodejs server would have no problem to serve thousands of parallel requests. You can't really justify having 5000 ruby threads, they are heavy and they will use too much memory.

Lio 6y ago
If you wanted to run 5000 parallel async requests in MRI ruby surely you'd just use a simple thread pool wouldn't you? If you prefer some other paradigm then Concurrent Ruby[1] has a swiss army knife of them including event loops and Go style SCP. I think things will improve in ruby 3 but even without ractors it's still possible to do either async IO in MRI or use JRuby for fully parallel ruby. 1. https://github.com/ruby-concurrency/concurrent-ruby https://github.com/ruby-concurrency/concurrent-ruby
- speedgoose 6y ago
  It's good to see that Ruby is getting some async IO. Hopefully Rails and the other frameworks will use it.
  - Lio 6y ago
    This is not really a new thing but maybe it's not well known. Ruby's had aysnc IO support for at at least 10 years I think. Rails itself has been using Concurrent Ruby since at least Rails 5 but I think it had its own concurrency patterns even before that. e.g. ActiveRecord database drivers. Jesse Storimer's Working with Ruby Threads book from 2013 is still a really good resource for concurrency in ruby.