When comparing Ruby vs Elm, the Slant community recommends Ruby for most people. In the question“What is the best programming language to learn first?” Ruby is ranked 10th while Elm is ranked 13th. The most important reason people chose Ruby is:
Ruby is one of the most popular languages for developing web sites. As a result, there's an abundant amount of documentation, sample code, and libraries available for learning the language and getting your project up and running. The most popular features are just 'gem install' away. Additionally, it is easier to find Ruby jobs because of this.
Specs
Ranked in these QuestionsQuestion Ranking
Pros
Pro Widely used
Ruby is one of the most popular languages for developing web sites. As a result, there's an abundant amount of documentation, sample code, and libraries available for learning the language and getting your project up and running. The most popular features are just 'gem install' away. Additionally, it is easier to find Ruby jobs because of this.
Pro Clean syntax
Ruby has a very clean syntax that makes code easier to both read and write than more traditional Object Oriented languages, such as Java. For beginning programmers, this means the focus is on the meaning of the program, where it should be, rather than trying to figure out the meaning of obscure characters.
presidents = ["Ford", "Carter", "Reagan", "Bush1", "Clinton", "Bush2"]
for ss in 0...presidents.length
print ss, ": ", presidents[presidents.length - ss - 1], "\n";
end

Pro A large ecosystem of tools & libraries
Ruby has a large ecosystem of tools and libraries for just about every use. Such as ORMs (Active Record, DatabMapper), Web Application Frameworks(Rails, Sinatra, Volt), Virtualization Orchestration(docker-api, drelict), CLI tools(Thor, Commando), GUI Frameworks(Shoes, FXRuby) and the list goes on. If you can think of it, there is probably a gem for that ( and if not you can create your own and share with the community).
Pro Newbie-friendly community
Pro Essential algorithmic features
The Ruby language is equipped with the necessary features to learn the essence of algorithms.
In online playground environments like ideone.com, measures have been taken to prevent beginners from going astray by restricting the use of external libraries such as Python's NumPy and SymPy.
Even in such constrained Ruby execution environments, the required features for learning algorithms are fully available.
Many of the algorithms that should be learned are documented in the book "Hello Ruby: Adventures in Coding." For example, the cake serving problem in the book leads to topological sorting, which is a graph theory concept useful in project management for creating Gantt charts.
To evaluate the effectiveness of algorithms with a level of complexity comparable to topological sorting,
it is necessary to be able to solve mathematical computation problems up to the high school level easily.
As shown in the table below, using only Ruby's standard library, it is possible to solve high school-level math problems effortlessly.
However, other programming languages may not be able to perform such computations in online playground environments.
To experience the superior performance of algorithms, it is important to challenge oneself by reimplementing good algorithms. Ruby's standard library includes implementations of excellent algorithms. For instance, the algorithm for solving linear equations, which has been widely known since the era of Fortran, is used within the code of SolvingLinearEquations through the "/" operator. Reimplementing code from Ruby's standard library serves as an excellent learning resource with high reusability and efficiency.
The SolvingLinearEquations function mentioned above demonstrates the benefits of duck typing and forced type conversion between objects of different types in arithmetic operations. While Rust also has features like duck typing, the implementation of "forced type conversion" is still far from being realized.
Mathematical Problem Type | Ruby Standard Library | Python Standard Library |
---|---|---|
Long Integer and Fraction | ✓ | ✓ |
Long Integer and Complex Fraction | ✓ | ✖ |
Operations on Matrices with Multiple-Digit Numbers as Coefficients | ✓ | ✖ |
Solution of Integer Coefficient Systems of Equations | ✓ | ✖ |
Solution of Systems of Equations with Long Integer and Complex Fraction Coefficients | ✓ | ✖ |
Solutions of Linear Equations with Real, Fraction, Complex, and Complex Fraction Coefficients | ✓ | ✖ |
# Title: "(1) Cake Serving Procedure Problem"
require 'tsort'
class Hash
include TSort
alias tsort_each_node each_key
def tsort_each_child(node, &block)
fetch(node).each(&block)
end
end
puts 'Tasks'
task_names = {
'A' => 'Arrange the plates.',
'B' => 'Set the spoons.',
'C' => 'Place the birthday cake on the table.',
'D' => 'Spread the tablecloth.'
}
p task_names
puts 'Preceding Tasks'
preceding_tasks = {
'A' => ['D'],
'B' => ['C', 'A'],
'C' => ['A', 'D'],
'D' => []
}
steps = preceding_tasks.strongly_connected_components
puts 'The appropriate steps are as follows:'
steps.each do |task_candidates|
p task_candidates.map { |task| [task, task_names[task]] }
end
p "#(2) Equation Solving Rule"
def SolvingLinearEquations(y, a, b)
x = (y - b) / a
end
p "(2-1) Real Solution", SolvingLinearEquations(1.0, 5, 0.5)
# => 0.1
p "(2-2) Fraction Solution", SolvingLinearEquations(Rational(1, 1), Rational(5, 1), Rational(1, 2))
# => (1/10)
p "(2-3) Imaginary Solution", SolvingLinearEquations(1 + 1i, 5, 1.0 / (2 + 2i))
# => (0.15+0.25i)
p "(2-4) Complex & Fraction Solution", SolvingLinearEquations(Rational(1 + 1i, 1), Rational(5, 1), Rational(1, 2 + 2i))
# => ((3/20)+(1/4)*i)
p "(2-5) Matrix Solution with Large Integers",
SolvingLinearEquations(Matrix[[Rational(1234567890123456789890, 1), Rational(0, 1)]],
Matrix[[Rational(1234567890123456789890, 1), Rational(1234567890123456789890 * 2, 1)],
[Rational(1234567890123456789890, 1), Rational(1234567890123456789890 * 3, 1)]],
Matrix[[Rational(1234567890, 1), Rational(123456789, 1)]] )
# => Matrix[[(3703703670366790122789/1234567890123456789890), (-2469135780244567900789/1234567890123456789890)]]
p "(2-7) Matrix Solution with Large Integers, Complex Numbers, and Fractions",
SolvingLinearEquations(Matrix[[Rational(1234567890123456789890, 1i), Rational(0, 1)]],
Matrix[[Rational(1234567890123456789890, 1), Rational(1234567890123456789890 * 2, 1i)],
[Rational(1234567890123456789890, 1), Rational(1234567890123456789890 * 3, 1i)]],
Matrix[[1234567890, 0 + 1i]] )
# => Matrix[[((-3703703671/1234567890123456789890)-(3/1)*i), ((2469135781/1234567890123456789890)+(2/1)*i)]]
Pro Ruby on Rails
Lays out an easy to follow and opinionated MVC pattern that teaches best practices through necessity.
Pro Test Driven Development, #1
It's the fore-runner and trend setter for TDD.
Pro Hugely object oriented
Object oriented programming is one of the most important concepts in programming.
Pro Meta-programming
Meta-programming provides efficiency and freedom.
Pro No indentation
No indentation increase development efficiency.
Pro Pry
Pro No run-time exceptions
Lack of run-time exceptions makes it easy to produce large swathes of reliable front-end code without drowning in tests.

Pro Inferred static typing
ML static typing is great because it's always there, you just choose how explicit you want to be and how much you want the compiler to do.

Pro Super easy refactoring with very helpful compiler errors
In no other language you can refactor so easy without any worries, since the compiler will guide you through. It is like TDD but than compiler-error driven.
Pro Designed around high-level front-end development
As Elm was designed as a front-end langauge, it has out of the box support for things like DOM-element creation, letting programmers focus on their application logic, rather than implementation details specific to the web.
Pro Great and simple way to learn Purely Functional Programming
You can try to apply some functional programming ideas in other languages that have an imperative basis, but you haven't seen the real power unless you tried it in the environment of purely functional programming. Elm is a simple language with great learning resources and easy graphical output, which makes it easy to explore the power of functional programming. Plus programming in Elm is very readable.

Pro Good tooling
All major editors have great support. With Atom for example, Elm plugins are available for linting, formatting, make/compiler support and Elmjutsu will simply overflow you with super useful functions, like navigate to referenced definition and show expression type.
Pro Batteries included
The Elm Architecture means you don't need to spend valuable time and effort choosing the right frameworks, state management libraries, or build tooling. It's all built in.
Pro Static module system
Elm uses easy to use modules.
Use:
import List
import List as L
import List exposing (..)
import List exposing ( map, foldl )
import Maybe exposing ( Maybe )
import Maybe exposing ( Maybe(..) )
import Maybe exposing ( Maybe(Just) )
Creation:
module MyModule exposing (foo, bar)

Pro Missing syntactic sugar
Easy to learn, most functions have only one way, not 5 alternatives where you must study where to best use what.
Pro Growing community
Pro Interactive Programming and Hot Swapping
Support for hot swapping and interactive programming is included.
Pro Easy to code review
The lack of side-effects and simple, consistent language semantics make it easy to quickly review incoming changes.
Pro Higher confidence in code correctness and quality
Pure functions, immutable data structures, amazing compiler, clean and homologous syntax used for HTML, logic, and optionally to replace CSS, elimination of entire classes of bugs so you don't even need most unit tests. These factors lead to better code, better programs, higher confidence, and ultimately, more satisfaction.

Pro Not quite Haskell semantics
Luckily you do not have to learn Haskell to be able to do any Elm. It is meant to be a language that compiles to Javascript, so for Javascript programmers (Front end) not for CS students who want to learn as many different algorithms as possible.
Cons
Con Monkeypatching
Requiring a library can change the rules of the language. This is very confusing for beginners.
Con Its ecosystem is limited outside of web development
If you're looking to host, generate, manipulate or secure a website, Ruby is your language. There's also some great support here for infrastructure as code work via Chef. However, it just doesn't have the depth and breadth that Python does. Things like native UI development, high performance math, and embedded / small footprint environments are barely supported at all in Ruby-space.
Con Arcane grammar based on Perl
Ruby is too complicated for beginners:
- arcane Perlisms;
- semi-significant whitespace;
- parentheses are not necessary around method arguments, except for sometimes they are;
- control constructs could be elegantly implemented with block like Smalltalk (Instead they're baked into the grammar.);
- verbose block syntax, unless it happens to be the last argument. (proc lambda).
- There are too many exceptional cases and arcane precedence rules.
Con Meta-programming causes confusion for new developers
The ability for libraries to open classes and augment them leads to confusion for new developers since it is not clear who injected the functionality into some standard class.
In other words, if two modules decide to modify the same function on the same class can introduce a number of issues. Mainly, the order in which the modules are included matters. Since you more or less can't tell what kind of "helper" functions a module might write into any class, or for that matter, where the helper function was included from, you may sometimes wonder why class X can do Y sometimes but not at other times.
Con No docstrings
It's hard to access Ruby's documentation from the REPL (irb), unlike Python, Lisp, and Smalltalk which let you ask functions how to use them, which is a great benefit to the beginner, and which also encourages you to document your program as you code it.
Con More than one way to do it
A problem inspired by Perl. The core API interfaces are bloated. There's at least four different ways to define methods. More is not always better. Sometimes it's just more.
Con Does not teach you about data types
Since Ruby is a dynamically typed language, you don't have to learn about data types if you start using Ruby as your first language. Data types being one of the most important concepts in programming. This also will cause trouble in the long run when you will have to (inevitably) learn and work with a statically typed language because you will be forced to learn the type system from scratch.
Con Dynamic type system
Majority of bugs could be resolved with types.
Con Viewed as a web development language
Despite its flexibility and performance, Ruby is often seen as being unsuitable for other tasks by those who are not familiar with it. As such, a lot of discussion about it centers around Rails, which is not at all relevant if you're using Ruby for something else, such as game development.
Con Focus on Object-Oriented Programming (OOP)
Focussing on OOP in a beginner stage is an easy and popular plan, but not the best one.
Con Lack of typeclasses
Elm doesn't have typeclasses which means some code needs to be duplicated. A fix in a function that needs typeclasses means all of the duplicates need to be fixed too.
Con limited js interop
only one way ports are available as a crude js FFI. This means you can only call functions both directions but will not get a result.
Con Harder to get buy-in from devs and mgmt
It's a total divergence from what most people are used to in the JS ecosystem. The change in syntax can be scary, the change in approaching problems can be scary. The fact that it's not backed by FANG can be scary. The fact that it's not v1.0 can be scary. The governance model and the deliberately slow release cadence can be scary. There are a couple harsh medium articles, hackernews/reddit posts out there made by people with an ax to grind that can be scary if you don't have a better picture of the Elm community, the tradeoffs that have been made, or the benefits to be had over other options. None of these are good reasons to write off further investigation of a great tech, but it happens.
Con Code Repetition
Because of the lack of genericness Elm needs a lot of code to be repeated. There are 130+ implementations of map in elms core libraries.
Con Features get removed without warning
Often features that are deemed to be misused by the community like infix operators get removed without much of a warning.
Con Community harsh if criticised
If one even dares to start a discussion about a feature on elms slack, discord, subreddit or github one will be aggressively shut down often argueing that one should use purescript instead
Con Poor Windows support
Few if any of Elm's core contributors are Windows users and breaking bugs are sometimes left for weeks or months.
Con Good for beginners not good for experts
Development in elm is quite nice until you need some more advanced features. These however are actively discontinued and removed because elm wants to establish a "single way of doing things" philosophy
Con Updates break existing code often
The last few updates of elm broke existing code in major ways.
Con Adds an additional layer of abstraction
Some users claim that Elm adds an additional layer of abstraction, meaning that it is one more hurdle between the brain and the product.
Con Functional programming itself has quite a steep learning curve
Functional programming can be quite difficult to get your head around. It takes time to unlearn object orientational habits.
Con No Genericness in the future
Currently there is no code genericness like typeclasses possible, it has been officially stated that this will never change.
Con Not database-friendly
It is lots of work to make a server or database your "one source of truth", as Elm makes you write endless JSON parse boilerplate to talk to the server.
Con No Syntactic Sugar
Often you need to write longer and less readable code because there are no alternatives that are more concise.
