When comparing Elm vs Bash (Bourne-Again SHell), the Slant community recommends Elm for most people. In the question“What is the best programming language to learn first?” Elm is ranked 13th while Bash (Bourne-Again SHell) is ranked 34th. The most important reason people chose Elm is:
Lack of run-time exceptions makes it easy to produce large swathes of reliable front-end code without drowning in tests.
Specs
Ranked in these QuestionsQuestion Ranking
Pros
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.
Pro Default shell on most systems
Bash is the default shell on virtually every UNIX system. Making it very portable across different systems and once you get used to it, you can use it everywhere.
Pro Plenty of examples and tutorials
Since this is very mature shell there is a lot of great examples and other resources describing how to do almost everything.
Pro Rich scripting capabilities on a single line
Want to run something 5 times? Write a throw-away loop: for i in 1 2 3 4 5; do date; done
If you need it 100 times? Not a problem: for i in {1..100}; do date; done
or: for ((i=0; i<100; ++i)); do date; done
How about emailing yourself when remote server is back online? Sure thing: while ! ping -c1 example.com &>/dev/null; do date; sleep 5; done && mailx -s 'server is back!' me@myself.com
Pro POSIX compatible
Pro Emacs-like keyboard control
By default, BASH uses shortcuts and concepts very similar to Emacs, so learning one often results in familiarity with the other.
Pro Rich built-in features
By default, there are many built-in features. They make really complex and reliable programs possible. In comparison to dash, for example, you can do the same tasks in less time and fewer lines of code.
Pro Variables and aliases are listed the way they are built
alias
and set
will list aliases and variables in a format that can be run directly with no modifications. Even if the values contain \n.
This is handy if you want to modify a value.
Pro Recursive globbing
ls **/*.log
for example is supported by Bash if you set shopt -s globstar
.
Pro Man page is a trove of wonders
While the manual "page" is nearly a hundred pages long, it is actually surprisingly succinct and stuffed with good information. It is often better than Googling for answers when writing shell scripts. The way it is written makes it easy to stumble upon useful new programming features just by flipping through it .
NOTE: If you find it dense and hard to read at the command line, look for the PDF version.
Pro vi mode is more comprehensive than on other shells
Vi editing mode works without a glitch. "_" will print you the last argument of the latest command (zsh won't). VI mode is fast off the bat - You don't have to reset any variable (like "KEYTIMEOUT" in zsh) for that.
Pro Copyright license is GPL 3+
Bash is licensed under the GNU General Public License ≥3, which gives much stronger assurances that the right to use it can't be restricted.
For example, Microsoft would not be able to claim in court that, even though they've distributed Bash with the GPLv3, a license that explicitly grants people freedom, now Bash is essentially proprietary due to software patents and everyone who uses Bash owes them money. (This may sound ludicrous to those who were not alive when Microsoft tried a similar scheme against Linux fifteen years ago).
The GPLv3 is a license that reflects the genuine ethical issues that arise when people give their time and skills to collaboratively build software. While most people wouldn't insist that their UNIX shell is licensed under the GPLv3+, it does matter and is a big PRO for Bash.
Pro Built-in 'help'... helps a lot
Built-in 'help' provides quick and efficient help on builtins and keywords.
Pro Rich scripting capabilities
BASH scripting is a rich and robust language.
Cons
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.
Con Extremely complicated and inconsistent rules
In Bash, exceptions are the rule, not even all being described by the main page.
There are a grand total of 5 different ways of quoting, sometimes even when one does not want to, for instance in command substitutions. These are all based around preserving the literal meaning of every character, with an exception list. There is even an exception list to the exception list in 4 of the 5, regarding how the backslash behaves! The behavior of the backslash is also one of the quoting rules, so naturally, it also has an exception in how it works when it stands before a newline as compared to other characters.
Bash has several layers of interpretations, all to be kept in mind:
The ~ expands to the home of the current user. So if you store it in a variable, can you use it that way? Nope: tilde expansion comes before variable expansion.
Aha, so that's how it works! Then, since applying quotation happens after redirections are set up, it must mean that redirecting within quotes works, right? Nope: there is an exception! If a redirection symbol is not quoted, quotation around the symbol is observed, but is not removed. So, since variable expansion also comes after setting up redirections, and no exceptions are described here in the man page, getting the name of a file from a variable and using it as a target should not work, right? No: redirection does not actually take place when the symbols are being read, the symbols are merely removed and are noted for later, right before when the actual command runs.
Apart from 5 types of quotation, there are basically 2 quoting phases, 2 word splitting phases (with only one being controllable), and a tokenization phase on top of that.
If you have a command, it could be an alias, a special built in, a non-special built in, a symbolic link to a file, a regular file, a function, with different rules regarding how they can be overridden, if redirection happens before or after arguments have been passed (what does "time my_command 2>&1 >log_file" do?), etc.
This list is admittedly long, but it doesn't even scratch the surface of the bloat, complexity and inconsistencies of Bash.
Con GPL3 is not compatible with Apple's lawyers
Apple, one of the largest distributors of UNIX systems, only ships an ancient version of bash that predates the iPhone.
No one knows why as Apple hasn't said, but the version Apple includes in MacOS is from right before the license was updated to version 3 of the GNU GPL (General Public License). Other major companies (IBM, Microsoft) have had no problem shipping the latest version of bash
, so it's unclear what Apple's lawyers are averse to. The GPL has always said that if you distributed a program, you granted everyone the right to use it freely. The biggest change in version 3 was the addition, "...and that includes software patents."
This was necessary because back in 2006 Microsoft was demanding that any company that uses Linux pay them or get sued for infringing on their patents. They even took some companies, like TomTom, to court. No software which can be restricted retroactively like that is truly free, so GPL 3+ includes a clause saying that if you distribute the program, then you are also granting license to any patents you own that are necessary to run it.
What patents Apple has that bash could possibly infringe on is a mystery, but the bigger question is, Why does Apple even care? So what if they are granting people the right to run bash without being sued by Apple. It's not like they were planning on doing that, right?
Even though it is not bash's fault that it is not Apple Lawyer-approved, this is a CON for it because a lot of people use Apple products. While there are methods like brew
to install a current version of bash, Apple does not make it obvious to their customers what they are missing.
Con Compatibility can be a curse
One of bash's claims to fame is compatibility with previous versions of itself and historic shells. But, doing that means that new features are often written in tortured, awkward syntax that is not easy to learn. For example, bash uses the POSIX way of doing arithmetic: to add 5+3 you must put the numbers in double parentheses with a dollar sign at the start: x=$((5+3)). It is true that many shells suffer from this same CON, but since bash is such an important shell, it has less wiggleroom to ditch clunky ideas that might break existing scripts.
Con Lags behind on features compared to ZSH and Fish
People who wants power features or to customize their shell experience use zsh or fish.
Con Filename expansion is not consistent
filename expansion is not consistent. "echo *" will print the names of the files in your current dir, if there are any... and will print "*" if there are none.
Con Non-intuitive shell expansion in for loops
If there are no .sh files, this will print mask itself:
for filename in *.sh; do
echo $filename
done
Con No out-of-the-box command autocompletion
To have command autocompletion in bash you need to install third-party plug-ins.
Con One of the most dangerous languages around
What it is mostly used for are file system operations. Guess what it is bad at? Operating on files. It automatically splits and carries out filename expansion on every single string resulting from variable expansion and command substitution unless quoted, by default on whitespace, whilst spaces are very common in filenames.
Before that, it even does pathname expansion, so woe to anywone who does not want to actually operate on files, but has a globbing metacharacter stored anywhere in a variable.
This means what you store in a variable is not going to be what will ACTUALLY be accessed.
If an empty variable is unquoted, it disappears completely due to word splitting, sometimes leading to applications signalling a missing parameter at a wrong position.
If quoted however, said variables cannot be iterated over in a loop, no matter what character one uses for word splitting.
If you use any globbing pattern with a command, be sure to use -- after the option arguments or if none are present, before starting the pattern with a mandatory ./
Otherwise, another Bash script run gone wrong or a hacker can create files named like an option ("-f", for instance) and your program will happily accept it as such, if it results from globbing.
For interactive use, it is convenient. For programming, it is a no-go.
