Need advice about which tool to choose?Ask the StackShare community!


+ 1

+ 1
Add tool

Elixir vs Ruby: What are the differences?

  1. Syntax: One key difference between Elixir and Ruby lies in their syntax. Elixir uses a functional programming style with pattern matching, whereas Ruby follows an object-oriented approach with more traditional syntax.
  2. Concurrency: Elixir is built on the Erlang virtual machine, which is known for its lightweight processes and excellent support for concurrency. In contrast, Ruby's concurrency support is not as robust, often requiring additional libraries or frameworks.
  3. Scalability: Elixir's design for scalability and fault tolerance is inherent in its language constructs, making it a popular choice for building distributed systems. Ruby, while capable of handling scalable applications, may require more effort and third-party tools to achieve similar levels of scalability.
  4. Performance: Elixir is known for its high performance due to its ability to leverage multiple cores efficiently, making it suitable for high-demand applications. Ruby, while optimized for developer productivity, may not offer the same level of performance when handling large workloads.
  5. Community and Libraries: Ruby has a larger community and a vast ecosystem of libraries and frameworks, making it easier for developers to find solutions to common problems. Elixir, being a newer language, has a smaller community but is growing steadily with dedicated supporters and a focus on tooling for modern development needs.
  6. Error Handling: Elixir emphasizes the "let it crash" philosophy, where failures are expected and managed at a process level, promoting robust fault-tolerant systems. Ruby, on the other hand, traditionally uses exceptions for error handling, which can lead to different approaches to handling failures in applications.

In Summary, Elixir and Ruby differ in syntax, concurrency support, scalability, performance, community size, and error handling strategies.

Decisions about Elixir and Ruby

#rust #elixir So am creating a messenger with voice call capabilities app which the user signs up using phone number and so at first i wanted to use Actix so i learned Rust so i thought to myself because well its first i felt its a bit immature to use actix web even though some companies are using Rust but we cant really say the full potential of Rust in a full scale app for example in Discord both Elixir and Rust are used meaning there is equal need for them but for Elixir so many companies use it from Whatsapp, Wechat, etc and this means something for Rust is not ready to go full scale we cant assume all this possibilities when it come Rust. So i decided to go the Erlang way after alot of Thinking so Do you think i made the right decision?Am 19 year programmer so i assume am not experienced as you so your answer or comment would really valuable to me

See more
Ing. Alvaro Rodríguez Scelza
Software Systems Engineer at Ripio · | 12 upvotes · 364.9K views

I was considering focusing on learning RoR and looking for a work that uses those techs.

After some investigation, I decided to stay with C# .NET:

  • It is more requested on job positions (7 to 1 in my personal searches average).

  • It's been around for longer.

  • it has better documentation and community.

  • One of Ruby advantages (its amazing community gems, that allows to quickly build parts of your systems by merely putting together third party components) gets quite complicated to use and maintain in huge applications, where building and reusing your own components may become a better approach.

  • Rail's front end support is starting to waver.

  • C# .NET code is far easier to understand, debug and maintain. Although certainly not easier to learn from scratch.

  • Though Rails has an excellent programming speed, C# tends to get the upper hand in long term projects.

I would avise to stick to rails when building small projects, and switching to C# for more long term ones.

Opinions are welcome!

See more
Timm Stelzer
VP Of Engineering at Flexperto GmbH · | 18 upvotes · 618.7K views

We have a lot of experience in JavaScript, writing our services in NodeJS allows developers to transition to the back end without any friction, without having to learn a new language. There is also the option to write services in TypeScript, which adds an expressive type layer. The semi-shared ecosystem between front and back end is nice as well, though specifically NodeJS libraries sometimes suffer in quality, compared to other major languages.

As for why we didn't pick the other languages, most of it comes down to "personal preference" and historically grown code bases, but let's do some post-hoc deduction:

Go is a practical choice, reasonably easy to learn, but until we find performance issues with our NodeJS stack, there is simply no reason to switch. The benefits of using NodeJS so far outweigh those of picking Go. This might change in the future.

PHP is a language we're still using in big parts of our system, and are still sometimes writing new code in. Modern PHP has fixed some of its issues, and probably has the fastest development cycle time, but it suffers around modelling complex asynchronous tasks, and (on a personal note) lack of support for writing in a functional style.

We don't use Python, Elixir or Ruby, mostly because of personal preference and for historic reasons.

Rust, though I personally love and use it in my projects, would require us to specifically hire for that, as the learning curve is quite steep. Its web ecosystem is OK by now (see, but in my opinion, it is still no where near that of the other web languages. In other words, we are not willing to pay the price for playing this innovation card.

Haskell, as with Rust, I personally adore, but is simply too esoteric for us. There are problem domains where it shines, ours is not one of them.

See more
Andrew Carpenter
Chief Software Architect at Xelex Digital, LLC · | 16 upvotes · 409.9K views

In 2015 as Xelex Digital was paving a new technology path, moving from ASP.NET web services and web applications, we knew that we wanted to move to a more modular decoupled base of applications centered around REST APIs.

To that end we spent several months studying API design patterns and decided to use our own adaptation of CRUD, specifically a SCRUD pattern that elevates query params to a more central role via the Search action.

Once we nailed down the API design pattern it was time to decide what language(s) our new APIs would be built upon. Our team has always been driven by the right tool for the job rather than what we know best. That said, in balancing practicality we chose to focus on 3 options that our team had deep experience with and knew the pros and cons of.

For us it came down to C#, JavaScript, and Ruby. At the time we owned our infrastructure, racks in cages, that were all loaded with Windows. We were also at a point that we were using that infrastructure to it's fullest and could not afford additional servers running Linux. That's a long way of saying we decided against Ruby as it doesn't play nice on Windows.

That left us with two options. We went a very unconventional route for deciding between the two. We built MVP APIs on both. The interfaces were identical and interchangeable. What we found was easily quantifiable differences.

We were able to iterate on our Node based APIs much more rapidly than we were our C# APIs. For us this was owed to the community coupled with the extremely dynamic nature of JS. There were tradeoffs we considered, latency was (acceptably) higher on requests to our Node APIs. No strong types to protect us from ourselves, but we've rarely found that to be an issue.

As such we decided to commit resources to our Node APIs and push it out as the core brain of our new system. We haven't looked back since. It has consistently met our needs, scaling with us, getting better with time as continually pour into and expand our capabilities.

See more
Thomas Miller
Talent Co-Ordinator at Tessian · | 16 upvotes · 234.4K views

In December we successfully flipped around half a billion monthly API requests from our Ruby on Rails application to some new Python 3 applications. Our Head of Engineering has written a great article as to why we decided to transition from Ruby on Rails to Python 3! Read more about it in the link below.

See more
Mike Fiedler
Enterprise Architect at Warby Parker · | 3 upvotes · 226.5K views

When I was evaluating languages to write this app in, I considered either Python or JavaScript at the time. I find Ruby very pleasant to read and write, and the Ruby community has built out a wide variety of test tools and approaches, helping e deliver better software faster. Along with Rails, and the Ruby-first Heroku support, this was an easy decision.

See more
Get Advice from developers at your company using StackShare Enterprise. Sign up for StackShare Enterprise.
Learn More
Pros of Elixir
Pros of Ruby
  • 172
  • 161
  • 133
    Erlang vm
  • 112
    Great documentation
  • 105
    Great tooling
  • 86
    Immutable data structures
  • 81
    Open source
  • 77
  • 62
    Easy to get started
  • 59
    Actor library
  • 32
    Functional with a neat syntax
  • 29
    Ruby inspired
  • 25
    Erlang evolved
  • 24
  • 22
    Beauty of Ruby, Speed of Erlang/C
  • 17
    Fault Tolerant
  • 14
  • 13
    High Performance
  • 11
    Pipe Operator
  • 11
    Good lang
  • 11
    Doc as first class citizen
  • 9
    Fun to write
  • 9
    Stinkin' fast, no memory leaks, easy on the eyes
  • 8
    Resilient to failure
  • 8
  • 6
    GenServer takes the guesswork out of background work
  • 4
  • 4
    Pattern matching
  • 4
    Not Swift
  • 4
    Fast, Concurrent with clean error messages
  • 3
    Easy to use
  • 2
    Error isolation
  • 2
    Dynamic Typing
  • 605
    Programme friendly
  • 536
    Quick to develop
  • 490
    Great community
  • 468
  • 432
  • 273
    Open source
  • 234
  • 207
  • 156
  • 139
    Powerful one-liners
  • 69
  • 58
    Easy to learn
  • 51
    Easy to start
  • 42
  • 37
  • 30
  • 21
    Fun to write
  • 19
    Diverse web frameworks
  • 13
    Reads like English
  • 10
    Makes me smarter and happier
  • 9
  • 8
    Very Dynamic
  • 8
    Elegant syntax
  • 6
  • 5
    Object Oriented
  • 5
    Programmer happiness
  • 4
    Elegant code
  • 4
    Generally fun but makes you wanna cry sometimes
  • 4
  • 4
    Fun and useful
  • 3
    Easy packaging and modules
  • 3
    There are so many ways to make it do what you want
  • 2
    Primitive types can be tampered with

Sign up to add or upvote prosMake informed product decisions

Cons of Elixir
Cons of Ruby
  • 11
    Fewer jobs for Elixir experts
  • 7
    Smaller userbase than other mainstream languages
  • 5
    Elixir's dot notation less readable ("object": 1st arg)
  • 4
    Dynamic typing
  • 1
    Difficult to understand
  • 1
    Not a lot of learning books available
  • 7
    Memory hog
  • 7
    Really slow if you're not really careful
  • 3
    Nested Blocks can make code unreadable
  • 2
    Encouraging imperative programming
  • 1
    Ambiguous Syntax, such as function parentheses

Sign up to add or upvote consMake informed product decisions

What is Elixir?

Elixir leverages the Erlang VM, known for running low-latency, distributed and fault-tolerant systems, while also being successfully used in web development and the embedded software domain.

What is Ruby?

Ruby is a language of careful balance. Its creator, Yukihiro “Matz” Matsumoto, blended parts of his favorite languages (Perl, Smalltalk, Eiffel, Ada, and Lisp) to form a new language that balanced functional programming with imperative programming.

Need advice about which tool to choose?Ask the StackShare community!

What companies use Elixir?
What companies use Ruby?
See which teams inside your own company are using Elixir or Ruby.
Sign up for StackShare EnterpriseLearn More

Sign up to get full access to all the companiesMake informed product decisions

What tools integrate with Elixir?
What tools integrate with Ruby?

Sign up to get full access to all the tool integrationsMake informed product decisions

Blog Posts

Nov 20 2019 at 3:38AM


Oct 24 2019 at 7:43PM


Jun 6 2019 at 5:11PM


What are some alternatives to Elixir and Ruby?
Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language.
Some of Erlang's uses are in telecoms, banking, e-commerce, computer telephony and instant messaging. Erlang's runtime system has built-in support for concurrency, distribution and fault tolerance. OTP is set of Erlang libraries and design principles providing middle-ware to develop these systems.
Clojure is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language - it compiles directly to JVM bytecode, yet remains completely dynamic. Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system.
Rust is a systems programming language that combines strong compile-time correctness guarantees with fast performance. It improves upon the ideas of other systems languages like C++ by providing guaranteed memory safety (no crashes, no data races) and complete control over the lifecycle of memory.
It is a general purpose language that can be used in any domain and use case, it is ideally suited for proprietary business logic and data analysis, fast prototyping and enhancing existing software environments with correct code, performance and scalability.
See all alternatives