31–40 of 50 posts
Earlier quoted context omitted.
All that being said, Ruby is much more like Smalltalk than Elixir or Erlang are. Smalltalk does have inheritance and classes, and does the kind of meta stuff easily that Ruby supports. Objects and classes are as central to Smalltalk's design as message passing is.
To touch on what digitalzombie said however, Kay did not originally picture inheritance as being part of OOP.
Classes in general hurt.
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.
They know where the skeletons are and avoid things that are bad ideas in that are if possible.
Earlier quoted context omitted.
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?
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 languag…
Fortunately, Rustler is making adding safe native extensions much easier. https://github.com/ddresselhaus/primal_ex is a little toy library I wrote to leverage a really excellent Primal Rust library. I'm excited about the possibilities Rustler brings to the table.
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…
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.
Earlier quoted context omitted.
Elixir isn't an object-oriented language.
alternatively it is the most object oriented language
Earlier quoted context omitted.
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 w…
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.
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.
Earlier quoted context omitted.
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.
.... 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.
Earlier quoted context omitted.
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.
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.
- 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
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…
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 w…
Earlier quoted context omitted.
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?
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 languag…