Re:Introducing Ruvy
by vidarh on Thursday October 26, 2023 @07:00AM
(#38023984)
I find that interesting because I've not run into a single scenario where I can't keep Ruby, so I'm curious where that's an issue for you. I suspect part of it is a different level of tolerance for wrapping tools instead of switching to their native languages. E.g. faced with "having" to use a Python project I'd be more inclined to wrap it in Ruby than writing Python.
As for concurrency, my default assumption in any language is to go multi process unless there is a measurable reason why that is too costly, because it means I can then generally scale seamlessly to multiple physical servers too when needed with nothing more than fork(), spawn(), and DrB or TcpServer once you want to farm it out across machines.
I used to render map tiles in Ruby that way, for example, and it scaled effortlessly to hundreds of cores.
Or to take another example: My text editor is fully concurrent and in Ruby - the buffers reside in a separate process and multiple concurrent processes, be it viewers/editors or utility scripts can simultaneously operate on the same buffer via DrB.
As for concurrency, my default assumption in any language is to go multi process unless there is a measurable reason why that is too costly, because it means I can then generally scale seamlessly to multiple physical servers too when needed with nothing more than fork(), spawn(), and DrB or TcpServer once you want to farm it out across machines.
I used to render map tiles in Ruby that way, for example, and it scaled effortlessly to hundreds of cores.
Or to take another example: My text editor is fully concurrent and in Ruby - the buffers reside in a separate process and multiple concurrent processes, be it viewers/editors or utility scripts can simultaneously operate on the same buffer via DrB.