5 ms·

Ruby and Python have had built in support for threads since the beginning, and they both have 'community standard' libraries for doing async IO: https://twiste

by fyfy18 8y ago

Ruby and Python have had built in support for threads since the beginning, and they both have 'community standard' libraries for doing async IO: https://twistedmatrix.com/trac/ https://twistedmatrix.com/trac/ https://github.com/eventmachine/eventmachine https://github.com/eventmachine/eventmachine (I guess Perl does too, but I haven't used Perl for 10 years) I admit the promise pattern may be simpler to understand, but if you need to build a heavily evented system Node doesn't provide anything unique that can't be achieved in other ecosystems.

hardwaresofton 8y ago
This is right, but only with a very limited interpretation for "support for threads", which does not include actual parallel computation. Not only is there a problem with the GIL, the only "threading" that ruby and python support natively is the spawn-another-process-and-find-a-way-to-coordinate kind (ala multiprocessing[0] in python). Also, the async IO support via libraries are there for ruby and python, but that brought along with it significant fragmentation (at the very least in the python case, I know less about ruby) -- no one was 100% sure whether to use tornado, twisted, gevent/eventlet for a very long time. A quote from another comment I wrote[1]: >> If we really want to get in the weeds, we could talk about python 2.x's floundering around async IO -- IIRC Twisted/Tornado/Gevent/Eventlet were all close to equally good options (and thus mindshare was split) while node had it built in, with a virtualenv-by-default packaging system. Also there's WSGI -- the interoperability it provides is cool, but also means more moving parts than a simple node+express setup. [EDIT] - It's a little unfair of me to decry the fact that multiple good solutions existed as a bad thing when I'd say it was a strength of the ecosystem. I do think it's valid to discuss the issues with packages that weren't compatible across interface boundaries between these async io libraries though. > (I guess Perl does too, but I haven't used Perl for 10 years) Same here, it's been a similar duration since I've used Perl for anything but even back then, the major difference between perl and the others was extremely good native regex support and the ability to spawn system threads that actually ran in parallel without coordinating another process. > I admit the promise pattern may be simpler to understand, but if you need to build a heavily evented system Node doesn't provide anything unique that can't be achieved in other ecosystems. My point was about the ease of achieving it... In the last ~3 years I've seen a wave of articles in the python blogosphere about how to properly use asyncio and all these new async-enabled libraries pop up (the old ones that relied on twisted/eventlet/whatever else are still around of course and perfectly good) -- what I'm saying is that JS has had this since the get go, and it's been thrashing python/ruby on benchmarks that favor the usecase for the same amount of time, especially if someone doesn't use one of the appropriate libraries. NodeJS's async io story is "batteries included", and that's huge in this day and age. Whether node has the right interface or if they made it ergonomic enough is a whole 'nother thing though... [0]: https://docs.python.org/3/library/multiprocessing.html https://docs.python.org/3/library/multiprocessing.html [1]: https://news.ycombinator.com/item?id=18756083 https://news.ycombinator.com/item?id=18756083
- est31 8y ago
  > the only "threading" that ruby and python support natively is the spawn-another-process-and-find-a-way-to-coordinate kind Are Javascript workers something different?
  - akvadrako 8y ago
    According to the Node 11 docs, worker threads are more lightweight than processes, but still heavy. That makes me think they run in the same address space, but use separate runtimes. So it's more scalable than ruby and python threads or multiprocessing.
    - hardwaresofton 8y ago
      A good article on them: https://medium.com/lazy-engineering/node-worker-threads-b57a32d84845 https://medium.com/lazy-engineering/node-worker-threads-b57a...
    - jashmatthews 8y ago
      JRuby doesn't have a GIL to begin with so there's no requirement to use multiprocessing to host Rails apps etc. They're an improvement over a single GIL but not by much. IIUC, they're like Racket's Places: a complete duplication of the VM but sharing an address space. The basic implementation doesn't really save much memory but it's a bit more convenient. There's been a couple of attempts to implement subinterpreters for CRuby too.
      - regularfry 8y ago
        JRuby is an incredibly underrated piece of kit. That startup time, though...
- jashmatthews 8y ago
  The GIL still allows for parallel IO so typical applications never need async. Modern Ruby just runs one process per core much like NodeJS in clustered mode or on JRuby with no GIL.
regularfry 8y ago
JRuby has Real, Proper, Actual Threads too. If you want parallel computation threads in Ruby, that's the way to go.

by fyfy18 8y ago

hardwaresofton 8y ago

This is right, but only with a very limited interpretation for "support for threads", which does not include actual parallel computation. Not only is there a problem with the GIL, the only "threading" that ruby and python support natively is the spawn-another-process-and-find-a-way-to-coordinate kind (ala multiprocessing[0] in python). Also, the async IO support via libraries are there for ruby and python, but that brought along with it significant fragmentation (at the very least in the python case, I know less about ruby) -- no one was 100% sure whether to use tornado, twisted, gevent/eventlet for a very long time. A quote from another comment I wrote[1]: >> If we really want to get in the weeds, we could talk about python 2.x's floundering around async IO -- IIRC Twisted/Tornado/Gevent/Eventlet were all close to equally good options (and thus mindshare was split) while node had it built in, with a virtualenv-by-default packaging system. Also there's WSGI -- the interoperability it provides is cool, but also means more moving parts than a simple node+express setup. [EDIT] - It's a little unfair of me to decry the fact that multiple good solutions existed as a bad thing when I'd say it was a strength of the ecosystem. I do think it's valid to discuss the issues with packages that weren't compatible across interface boundaries between these async io libraries though. > (I guess Perl does too, but I haven't used Perl for 10 years) Same here, it's been a similar duration since I've used Perl for anything but even back then, the major difference between perl and the others was extremely good native regex support and the ability to spawn system threads that actually ran in parallel without coordinating another process. > I admit the promise pattern may be simpler to understand, but if you need to build a heavily evented system Node doesn't provide anything unique that can't be achieved in other ecosystems. My point was about the ease of achieving it... In the last ~3 years I've seen a wave of articles in the python blogosphere about how to properly use asyncio and all these new async-enabled libraries pop up (the old ones that relied on twisted/eventlet/whatever else are still around of course and perfectly good) -- what I'm saying is that JS has had this since the get go, and it's been thrashing python/ruby on benchmarks that favor the usecase for the same amount of time, especially if someone doesn't use one of the appropriate libraries. NodeJS's async io story is "batteries included", and that's huge in this day and age. Whether node has the right interface or if they made it ergonomic enough is a whole 'nother thing though... [0]: https://docs.python.org/3/library/multiprocessing.html https://docs.python.org/3/library/multiprocessing.html [1]: https://news.ycombinator.com/item?id=18756083 https://news.ycombinator.com/item?id=18756083

est31 8y ago
> the only "threading" that ruby and python support natively is the spawn-another-process-and-find-a-way-to-coordinate kind Are Javascript workers something different?
- akvadrako 8y ago
  According to the Node 11 docs, worker threads are more lightweight than processes, but still heavy. That makes me think they run in the same address space, but use separate runtimes. So it's more scalable than ruby and python threads or multiprocessing.
  - hardwaresofton 8y ago
    A good article on them: https://medium.com/lazy-engineering/node-worker-threads-b57a32d84845 https://medium.com/lazy-engineering/node-worker-threads-b57a...
  - jashmatthews 8y ago
    JRuby doesn't have a GIL to begin with so there's no requirement to use multiprocessing to host Rails apps etc. They're an improvement over a single GIL but not by much. IIUC, they're like Racket's Places: a complete duplication of the VM but sharing an address space. The basic implementation doesn't really save much memory but it's a bit more convenient. There's been a couple of attempts to implement subinterpreters for CRuby too.
    - regularfry 8y ago
      JRuby is an incredibly underrated piece of kit. That startup time, though...
jashmatthews 8y ago
The GIL still allows for parallel IO so typical applications never need async. Modern Ruby just runs one process per core much like NodeJS in clustered mode or on JRuby with no GIL.

regularfry 8y ago

JRuby has Real, Proper, Actual Threads too. If you want parallel computation threads in Ruby, that's the way to go.