8 ms·

Ruby vs Elixir – Panel discussion at Wroc_love.rb [video]

75 points by jschepmans 9y ago

enraged_camel 9y ago
I think it comes down to this: with Elixir, you gain a lot over Ruby and lose very little. Any Elixir app will be significantly more performant and reliable than its Ruby counterpart. This is due to several reasons: - Elixir runs on a battle-tested virtual machine, and stuff like supervisor behavior (e.g. auto-restart of crashing processes) is built right in - Elixir is a functional language, which makes the code you write more testable - State in Elixir is immutable, which greatly reduces the side effects of running code I used to develop in Ruby circa 2014-2015. It will always have a special place in my heart, but to be frank, I don't really miss it. Elixir, as a language, is better in almost every way. And once the ecosystem becomes a bit more mature, it will be unstoppable (OK maybe not really, but it's definitely here to stay).
- amorphid 9y ago
  I love Elixir, and came from Ruby. I do find it hard to describe to people why I like it more it more. There is no one thing that is a killer feature to me. I do not miss inheritance at all.
  - brightball 9y ago
    IMO, Elixir appeals to developers who have experienced the challenges of the established code bases because you immediately realize the long term benefits of the way it's designed. I've noticed a pattern at least that it seems to appeal to people with more experience because it's easier to recognize what the little details bring.
  - regulation_d 9y ago
    Pattern matching, to me, is the killer feature. It allows me to write so many fewer if statements, which to me is a big boon.
    - amorphid 9y ago
      Here's a list of things Elixir things I love: - pattern matching - immutable data - built-in supervision tree - async message passing w/ mailboxes - networking modules - much of Elixir is written in Elixir Here's stuff I'd like to see in the standard library (which may come over time anyway): - Better time/calendar options (I still like using Timex) - Rational numbers - Ruby's BigDecimal in Elixir - Dialyzer for Elixir - No need to mess w/ Erlang data types (looking at you charlists) - Better semantics for process registry - Documentation on parallel testing options
      - _asummers 9y ago
        As far as Dialyzer, we use the dialyxir project, and it behaves well enough. Depending on how macro heavy your code gets, it gives up earlier than it should, but you can still get it to flag you for doing bad things when it gets down to modules calling modules. Combined with lint rules around making sure stuff has @spec, it catches a lot of things.
        amorphid 9y ago
        I use dialyxir, too. Mostly I was referring to wanting dialyzer to output Elixir syntax, not Erlang.
- pythonaut_16 9y ago
  It seemed like in the panel they just kept looping back to the performance and concurrency, to which the Ruby guys would say "So what, Ruby is fast enough for 99% of apps", completely ignoring all of the other strengths of Elixir.
  - digitalzombie 9y ago
    Because Elixir is better than Ruby in webapp space, in term of speed, you don't need to reach for caching and complex backend solution as early as RoR. I think this is a big win.
- losvedir 9y ago
  Former Ruby, now Elixir, developer here and I agree. The one use case where Ruby still wins for me, though, is a little one-off script. Last time I had occasion to do that, I found you couldn't use any Elixir hex packages without generating a whole mix application. In ruby you could just globally install the gem and require it right into your script. I forget why this came up, but I think it was something like just wanting to download a web page and parse out a certain bit of it into a CSV file or something like that. Pretty trivial in Elixir with HTTPoison and Floki, but no real way to use those in a one-off .exs file (I don't think?). Whereas in ruby, I've already got HTTParty and Nokogiri in there somewhere, and you can toss it together in a minute.
  - _asummers 9y ago
    Mix tasks are what you're looking for. You put them inside your application (we have them in /appa/your_app /lib/mix/tasks), define a run/1 function that takes in args, say "use Mix.Task", then you can make sure that things like Ecto are loaded and interact with your program's major entities, or use Poison or whatever it is that you care to do.
    - CrystalLangUser 9y ago
      .... Or you could create a script.rb file, anywhere, and require gems if needed. Then type ruby script.rb. That takes no time at all, and using gems is extremely simple even with RVM if wanted.
      - sjtgraham 9y ago
        That works for quick and dirty scripts but it's not portable if you want to distribute it to others.
  - amorphid 9y ago
    I like Ruby for one off scripts, too. In some cases though, I don't like having to install Ruby. If Elixir, or perhaps Erlang, is on the target box, an Elixir Escript is also a good option. I've picked up a fair bit of bash for easier tasks, too.
- brudgers 9y ago
  Playing around with Elixir, it seems like it loses Ruby's Smalltalk like "everything is an object" that allows things like: > 4.even? => true That's not to say that what Elixir provides is (or is not) worth giving up everything-is-an-object because Erlang's design does what it is supposed to do very very well.
  - brightball 9y ago
    There's basically data and functions, so 4 wouldn't really have any methods attached to it and instead you'd just call Number.even?(4). Purely psuedo code example. It's a deep subject but one of the biggest things is that it's virtually impossible to end up with the untenable monolith that many ruby apps eventually grow into. Since you aren't dealing with crazy inheritance trees attached to data separating things out really just becomes moving code around. I do both Ruby and Elixir code right now. There are times when I like the convenience of Ruby for command line scripts or monkey patching a quick modification for a 3rd party library...but there are other times when you hit problems that you just can't solve effectively without rewriting in something else and that gets annoying. That's one of the reasons you see so many posts about moving from Ruby to Go or Elixir because both languages are much better at Ruby's weakest points. But it's always worth noting that Ruby got those projects to market with maturity and helped them grow customer bases with enough traffic to JUSTIFY a rewrite. What gets people so excited about Elixir is that you lose very little in the development time department for full stack while avoiding the long term complications due to the language rules. All that said, it makes you think about problems differently which will be a challenge for people at first.
    - pawelduda 9y ago
      Or like this, thanks to the pipe operator 4 |> Integer.is_even Above can be even shortened if you import Integer module: import Integer (...) 4 |> is_even
      - _asummers 9y ago
        Collectively at work, we've abandoned the use of import, except when importing DSLs (e.g. Ecto) in favor of explicit function calls or alias. If we do need to use import, we use explicit "import Ecto.Query, only: [from: 2]", so that it's clear where a function is coming from into the namespace. Relatedly, unless otherwise necessary, __using__ macros through our code do not import modules, because it's surprising when something is in scope for no real reason. We often inline the third party __using__ macros to eliminate this.
- goatlover 9y ago
  It's different, but I'm not sure that makes it better than Ruby. You listed three advantages for Elixir. Are there none for Ruby? Language design involves tradeoffs. Are there no tradeoffs for being immutable and functional?
  - sanderjd 9y ago
    You're right that there are always tradeoffs, but it isn't clear that Ruby takes the other side of many of Elixir's. Some examples: Elixir requires a VM installed on the target machine (unlike Go, C, C++, etc.), it doesn't have strong type checking (unlike Java, Scala, Haskell, etc.), it doesn't have a strong data science story (unlike Python and R), it can't be conveniently used as a dual front- and back-end language (unlike javascript, TypeScript, etc.). But Ruby is on the same side of all those tradeoffs. Someone mentioned that Ruby is more useful for scripts because libraries can be installed and used at the system level; that seems true to me, so that's one example. But I think the main tradeoff that Ruby wins on is maturity. Which is a big deal to be sure.
    - derefr 9y ago
      > Ruby is more useful for scripts because libraries can be installed and used at the system level There's no reason Elixir can't do this. Or rather, for interactive scripting under iex(1) without a project scope, there's nothing stopping someone from adding a feature that 1. assumes some default project scope (e.g. "~/.mix/default"), and 2. allows you—even from within the REPL!—to add a dependency to "~/.mix/default/mix.exs", re-run the dependency constraint solver, and (if successful) compile + reload the Mix project, or (if failed) back out the mix.exs change. On the other side, for the use-case of "scripts as standalone redistributable binaries", I prefer Elixir's philosophy of "everything is vendored, always"—the [redistributable form of the] script just has all its deps inside it, much like SPA Javascript apps do. It's indeed true, though, that you can't achieve a hybrid of these use-cases: have your own personal set of IEx libraries loaded and able to be used to probe and debug within an existing Mix project that contains its own set of libraries, where these libraries' dep specifications—if combined in a single Mixfile—wouldn't constraint-solve. That is an annoying problem that I run into quite often, especially because Elixir doesn't ship with many tools I'd like to use during debugging, like a JSON library, and I end up having to alter the project's own Mixfile to add these deps, rather than just "bringing in" my own. At root, that problem is a semi-architectural problem with the Erlang VM: modules are indexed by [fully qualified] name, so—unlike in Javascript—you can't have "handles to" two modules with the same name. (But, actually, there's nothing about the design of Erlang or Elixir that requires the Erlang VM to work that way; it could be fixed, if people thought it'd be helpful.)
- amw-zero 9y ago
  Elixir and Ruby are so different, they shouldn't even be allowed to be compared. If you don't think so, try and write some medium-sized code challenges in both and see how different the implementations come out (try more than 3 because sometimes you can express the same idea in both in a similar way). "You gain a lot over Ruby and lose very little." "...better in almost every way." These are very shortsighted assertions. As engineers we should strive be a little more objective and at least mention pros and cons of both choices. For example, is ease of deployment important to you and your project? How do these languages compare there? Try not to get blinded by the honeymoon phase with a language.
- hdra 9y ago
  My biggest issue with Elixir right now is that in order to take advantage of its main selling points (process model, concurrency, etc), your running applications are essentially stateful. This adds some complexity to the way it is run, especially if the server load is highly dynamic, and you need to scale up and down instances every few hours. This means deployment and running a production elixir app is fundamentally "different", which leads to people reaching for hot code swapping, treating servers as "pet" instead of "livestock", etc. With tools like Kubernetes and containers taking over more and more of the ops world, running an Elixir application feels like swimming against the current as the BEAM VM have its own clustering system that requires some workaround to make it work well with an elastic auto-scaling cluster.
Prego 9y ago
As an old-school Erlang programmer, I don't want to water down the Beam ecosystem with an influx of Ruby "programmers." Sure, they may be able to cut and paste a Phoenix demo to get something sort-of working, but they have No Idea how everything works.
hartator 9y ago
I am falling for Elixir. However, my big drawback that made me stay in Ruby is the community don't seem to like NoSQL solutions like MongoDB and you can feel it in the libraries and global architecture.
- _asummers 9y ago
  It's just that they have their own ways of expressing it, using things like ETS, DETS, mnesia, Riak-core, depending on your use cases and consistency requirements.
- di4na 9y ago
  Because the erlang community (and core member of the elixir community) have quite a lot of experience with distributed systems and alternative to SQL. They know where the skeletons are and avoid things that are bad ideas in that are if possible.
tkyjonathan 9y ago
There is a thing that was missed. You may have developed an application very quickly with ruby and go to market faster in 6 months, but you spend the next 5 years trying to fix performance issues with barely writing any new features.

75 points by jschepmans 9y ago

I think it comes down to this: with Elixir, you gain a lot over Ruby and lose very little. Any Elixir app will be significantly more performant and reliable than its Ruby counterpart. This is due to several reasons: - Elixir runs on a battle-tested virtual machine, and stuff like supervisor behavior (e.g. auto-restart of crashing processes) is built right in - Elixir is a functional language, which makes the code you write more testable - State in Elixir is immutable, which greatly reduces the side effects of running code I used to develop in Ruby circa 2014-2015. It will always have a special place in my heart, but to be frank, I don't really miss it. Elixir, as a language, is better in almost every way. And once the ecosystem becomes a bit more mature, it will be unstoppable (OK maybe not really, but it's definitely here to stay).

amorphid 9y ago
I love Elixir, and came from Ruby. I do find it hard to describe to people why I like it more it more. There is no one thing that is a killer feature to me. I do not miss inheritance at all.
- brightball 9y ago
  IMO, Elixir appeals to developers who have experienced the challenges of the established code bases because you immediately realize the long term benefits of the way it's designed. I've noticed a pattern at least that it seems to appeal to people with more experience because it's easier to recognize what the little details bring.
- regulation_d 9y ago
  Pattern matching, to me, is the killer feature. It allows me to write so many fewer if statements, which to me is a big boon.
  - amorphid 9y ago
    Here's a list of things Elixir things I love: - pattern matching - immutable data - built-in supervision tree - async message passing w/ mailboxes - networking modules - much of Elixir is written in Elixir Here's stuff I'd like to see in the standard library (which may come over time anyway): - Better time/calendar options (I still like using Timex) - Rational numbers - Ruby's BigDecimal in Elixir - Dialyzer for Elixir - No need to mess w/ Erlang data types (looking at you charlists) - Better semantics for process registry - Documentation on parallel testing options
    - _asummers 9y ago
      As far as Dialyzer, we use the dialyxir project, and it behaves well enough. Depending on how macro heavy your code gets, it gives up earlier than it should, but you can still get it to flag you for doing bad things when it gets down to modules calling modules. Combined with lint rules around making sure stuff has @spec, it catches a lot of things.
      - amorphid 9y ago
        I use dialyxir, too. Mostly I was referring to wanting dialyzer to output Elixir syntax, not Erlang.
pythonaut_16 9y ago
It seemed like in the panel they just kept looping back to the performance and concurrency, to which the Ruby guys would say "So what, Ruby is fast enough for 99% of apps", completely ignoring all of the other strengths of Elixir.
- digitalzombie 9y ago
  Because Elixir is better than Ruby in webapp space, in term of speed, you don't need to reach for caching and complex backend solution as early as RoR. I think this is a big win.
losvedir 9y ago
Former Ruby, now Elixir, developer here and I agree. The one use case where Ruby still wins for me, though, is a little one-off script. Last time I had occasion to do that, I found you couldn't use any Elixir hex packages without generating a whole mix application. In ruby you could just globally install the gem and require it right into your script. I forget why this came up, but I think it was something like just wanting to download a web page and parse out a certain bit of it into a CSV file or something like that. Pretty trivial in Elixir with HTTPoison and Floki, but no real way to use those in a one-off .exs file (I don't think?). Whereas in ruby, I've already got HTTParty and Nokogiri in there somewhere, and you can toss it together in a minute.
- _asummers 9y ago
  Mix tasks are what you're looking for. You put them inside your application (we have them in /appa/your_app /lib/mix/tasks), define a run/1 function that takes in args, say "use Mix.Task", then you can make sure that things like Ecto are loaded and interact with your program's major entities, or use Poison or whatever it is that you care to do.
  - CrystalLangUser 9y ago
    .... Or you could create a script.rb file, anywhere, and require gems if needed. Then type ruby script.rb. That takes no time at all, and using gems is extremely simple even with RVM if wanted.
    - sjtgraham 9y ago
      That works for quick and dirty scripts but it's not portable if you want to distribute it to others.
- amorphid 9y ago
  I like Ruby for one off scripts, too. In some cases though, I don't like having to install Ruby. If Elixir, or perhaps Erlang, is on the target box, an Elixir Escript is also a good option. I've picked up a fair bit of bash for easier tasks, too.
brudgers 9y ago
Playing around with Elixir, it seems like it loses Ruby's Smalltalk like "everything is an object" that allows things like: > 4.even? => true That's not to say that what Elixir provides is (or is not) worth giving up everything-is-an-object because Erlang's design does what it is supposed to do very very well.
- brightball 9y ago
  There's basically data and functions, so 4 wouldn't really have any methods attached to it and instead you'd just call Number.even?(4). Purely psuedo code example. It's a deep subject but one of the biggest things is that it's virtually impossible to end up with the untenable monolith that many ruby apps eventually grow into. Since you aren't dealing with crazy inheritance trees attached to data separating things out really just becomes moving code around. I do both Ruby and Elixir code right now. There are times when I like the convenience of Ruby for command line scripts or monkey patching a quick modification for a 3rd party library...but there are other times when you hit problems that you just can't solve effectively without rewriting in something else and that gets annoying. That's one of the reasons you see so many posts about moving from Ruby to Go or Elixir because both languages are much better at Ruby's weakest points. But it's always worth noting that Ruby got those projects to market with maturity and helped them grow customer bases with enough traffic to JUSTIFY a rewrite. What gets people so excited about Elixir is that you lose very little in the development time department for full stack while avoiding the long term complications due to the language rules. All that said, it makes you think about problems differently which will be a challenge for people at first.
  - pawelduda 9y ago
    Or like this, thanks to the pipe operator 4 |> Integer.is_even Above can be even shortened if you import Integer module: import Integer (...) 4 |> is_even
    - _asummers 9y ago
      Collectively at work, we've abandoned the use of import, except when importing DSLs (e.g. Ecto) in favor of explicit function calls or alias. If we do need to use import, we use explicit "import Ecto.Query, only: [from: 2]", so that it's clear where a function is coming from into the namespace. Relatedly, unless otherwise necessary, __using__ macros through our code do not import modules, because it's surprising when something is in scope for no real reason. We often inline the third party __using__ macros to eliminate this.
goatlover 9y ago
It's different, but I'm not sure that makes it better than Ruby. You listed three advantages for Elixir. Are there none for Ruby? Language design involves tradeoffs. Are there no tradeoffs for being immutable and functional?
- sanderjd 9y ago
  You're right that there are always tradeoffs, but it isn't clear that Ruby takes the other side of many of Elixir's. Some examples: Elixir requires a VM installed on the target machine (unlike Go, C, C++, etc.), it doesn't have strong type checking (unlike Java, Scala, Haskell, etc.), it doesn't have a strong data science story (unlike Python and R), it can't be conveniently used as a dual front- and back-end language (unlike javascript, TypeScript, etc.). But Ruby is on the same side of all those tradeoffs. Someone mentioned that Ruby is more useful for scripts because libraries can be installed and used at the system level; that seems true to me, so that's one example. But I think the main tradeoff that Ruby wins on is maturity. Which is a big deal to be sure.
  - derefr 9y ago
    > Ruby is more useful for scripts because libraries can be installed and used at the system level There's no reason Elixir can't do this. Or rather, for interactive scripting under iex(1) without a project scope, there's nothing stopping someone from adding a feature that 1. assumes some default project scope (e.g. "~/.mix/default"), and 2. allows you—even from within the REPL!—to add a dependency to "~/.mix/default/mix.exs", re-run the dependency constraint solver, and (if successful) compile + reload the Mix project, or (if failed) back out the mix.exs change. On the other side, for the use-case of "scripts as standalone redistributable binaries", I prefer Elixir's philosophy of "everything is vendored, always"—the [redistributable form of the] script just has all its deps inside it, much like SPA Javascript apps do. It's indeed true, though, that you can't achieve a hybrid of these use-cases: have your own personal set of IEx libraries loaded and able to be used to probe and debug within an existing Mix project that contains its own set of libraries, where these libraries' dep specifications—if combined in a single Mixfile—wouldn't constraint-solve. That is an annoying problem that I run into quite often, especially because Elixir doesn't ship with many tools I'd like to use during debugging, like a JSON library, and I end up having to alter the project's own Mixfile to add these deps, rather than just "bringing in" my own. At root, that problem is a semi-architectural problem with the Erlang VM: modules are indexed by [fully qualified] name, so—unlike in Javascript—you can't have "handles to" two modules with the same name. (But, actually, there's nothing about the design of Erlang or Elixir that requires the Erlang VM to work that way; it could be fixed, if people thought it'd be helpful.)
amw-zero 9y ago
Elixir and Ruby are so different, they shouldn't even be allowed to be compared. If you don't think so, try and write some medium-sized code challenges in both and see how different the implementations come out (try more than 3 because sometimes you can express the same idea in both in a similar way). "You gain a lot over Ruby and lose very little." "...better in almost every way." These are very shortsighted assertions. As engineers we should strive be a little more objective and at least mention pros and cons of both choices. For example, is ease of deployment important to you and your project? How do these languages compare there? Try not to get blinded by the honeymoon phase with a language.
hdra 9y ago
My biggest issue with Elixir right now is that in order to take advantage of its main selling points (process model, concurrency, etc), your running applications are essentially stateful. This adds some complexity to the way it is run, especially if the server load is highly dynamic, and you need to scale up and down instances every few hours. This means deployment and running a production elixir app is fundamentally "different", which leads to people reaching for hot code swapping, treating servers as "pet" instead of "livestock", etc. With tools like Kubernetes and containers taking over more and more of the ops world, running an Elixir application feels like swimming against the current as the BEAM VM have its own clustering system that requires some workaround to make it work well with an elastic auto-scaling cluster.

Prego 9y ago

As an old-school Erlang programmer, I don't want to water down the Beam ecosystem with an influx of Ruby "programmers." Sure, they may be able to cut and paste a Phoenix demo to get something sort-of working, but they have No Idea how everything works.

hartator 9y ago

I am falling for Elixir. However, my big drawback that made me stay in Ruby is the community don't seem to like NoSQL solutions like MongoDB and you can feel it in the libraries and global architecture.

_asummers 9y ago
It's just that they have their own ways of expressing it, using things like ETS, DETS, mnesia, Riak-core, depending on your use cases and consistency requirements.
di4na 9y ago
Because the erlang community (and core member of the elixir community) have quite a lot of experience with distributed systems and alternative to SQL. They know where the skeletons are and avoid things that are bad ideas in that are if possible.

tkyjonathan 9y ago

There is a thing that was missed. You may have developed an application very quickly with ruby and go to market faster in 6 months, but you spend the next 5 years trying to fix performance issues with barely writing any new features.