2 ms·

It's perfectly fine :-) I've also used a lot of languages either professionally or not (ranging from assembly/bytecode to much higher level, c#, java, c++, bits

It's perfectly fine :-) I've also used a lot of languages either professionally or not (ranging from assembly/bytecode to much higher level, c#, java, c++, bits of rust etc etc), but I can perfectly see why you wouldn't find it appealing. In my case the main appeal is not the scalability/concurrency story (although it's great), nor the hot-swapping (I've done it with Ruby, C# and a couple more) or pluggability, it's more the increased number of scenarios where I can keep this single language (from scripting to "regular code" to embedded to, recently, machine learning). But if you do not feel compelled, well there is no reason to force! Compare to Ruby specifically, I find that the concurrency story is quite different (I have used concurrent-ruby, JRuby etc, and find the built-in tools in Elixir quite amazing, including Task.async_stream).

vidarh 3y ago
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.
- thibaut_barrere 3y ago
  I'll try to reply after my holidays :-)

vidarh 3y ago

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.

thibaut_barrere 3y ago
I'll try to reply after my holidays :-)