3 ms·

I am a long-time rubyist (since 2004 and still using it) but I do not think it is a safe bet of your time. I really need to prepare an article on that, but alt

I am a long-time rubyist (since 2004 and still using it) but I do not think it is a safe bet of your time. I really need to prepare an article on that, but although it is a bit weird and different initially (functional roots are less classic for most developers), I find that the « usage surface » of Elixir is much wider than Ruby’s, today. You can do pretty much everything you can do with Ruby (web apps, API, scripting…) but more trivially scalable (including things like real-time chats), and more: machine learning, computer vision, embedded, and soon mobile apps… Its interop story with Rust is fairly good and this allows interesting extensions (see Explorer, with integration with the fast Polars data frame library). Maintenance is overall good as well (for multiple reasons including core design), the churn is lower than Javascript, and the developer experience is improving on a regular basis. I am starting to meet with CS schools to see how to put this in the good hands of students :-)

vidarh 3y ago
> I find that the « usage surface » of Elixir is much wider than Ruby’s, today. Conversely, I hardly never see Elixir advertised from anywhere I pay attention to, including in several years working at a VC evaluating the technology of potential investments. I suspect we're both stuck in bubbles.
- thibaut_barrere 3y ago
  I meant it in the sense of « what can I do with it today », rather than the volume of uses seen in companies! I agree that it remains a niche language at the moment, something I am trying to change at my level.
  - vidarh 3y ago
    Then I find it an even stranger claim. I've done everything from statistics amd financial modelling, via web apps, image and sound processing to desktop apps in Ruby. For a few things people are best off using ffi to wrap compiled libraries, but there's never been anything I've wanted to do that I haven't been able to.
    - thibaut_barrere 3y ago
      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.

vidarh 3y ago

> I find that the « usage surface » of Elixir is much wider than Ruby’s, today. Conversely, I hardly never see Elixir advertised from anywhere I pay attention to, including in several years working at a VC evaluating the technology of potential investments. I suspect we're both stuck in bubbles.

thibaut_barrere 3y ago
I meant it in the sense of « what can I do with it today », rather than the volume of uses seen in companies! I agree that it remains a niche language at the moment, something I am trying to change at my level.
- vidarh 3y ago
  Then I find it an even stranger claim. I've done everything from statistics amd financial modelling, via web apps, image and sound processing to desktop apps in Ruby. For a few things people are best off using ffi to wrap compiled libraries, but there's never been anything I've wanted to do that I haven't been able to.
  - thibaut_barrere 3y ago
    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.