4 ms·

I was in the same boat as you until recently. I have done everything I can imagine with Ruby! But it turns out I can do them better & "more broadly" with Elixir

I was in the same boat as you until recently. I have done everything I can imagine with Ruby! But it turns out I can do them better & "more broadly" with Elixir. Note that I'm not trying to convince you, just sharing my experience :-)

vidarh 3y ago
I'm mostly curious, because I've not run into limits with Ruby that'd make me look elsewhere. I've used over a dozen languages professionally over the years, so when I have a reason to I pick another one, but Elixir has never felt compelling to me - I just don't see it offering enough new/different stuff to be worthwhile. I've built large-scale distributed systems, and so on one hand the features of the Erlang VM are appealing and I've enjoyed reading papers on it. On the other hand I know how to - and have - built similar concurrency, restart and auto-updating/hotswapping functionality in other languages (including Ruby, where it's fairly easy) and it doesn't require enough code to compel me to pick a language based on that.
- thibaut_barrere 3y ago
  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'm mostly curious, because I've not run into limits with Ruby that'd make me look elsewhere. I've used over a dozen languages professionally over the years, so when I have a reason to I pick another one, but Elixir has never felt compelling to me - I just don't see it offering enough new/different stuff to be worthwhile. I've built large-scale distributed systems, and so on one hand the features of the Erlang VM are appealing and I've enjoyed reading papers on it. On the other hand I know how to - and have - built similar concurrency, restart and auto-updating/hotswapping functionality in other languages (including Ruby, where it's fairly easy) and it doesn't require enough code to compel me to pick a language based on that.

thibaut_barrere 3y ago
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 :-)