When comparing C++ vs Elm, the Slant community recommends Elm for most people. In the question“What is the best programming language to learn first?” Elm is ranked 18th while C++ is ranked 22nd. 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.
Ranked in these QuestionsQuestion Ranking
Pro Huge language supports most everything
C++ is a large language with an even larger community and following. It has libraries for every kind of task that is possible to do with C++
Pro Powerful memory management
Allows puting large arrays on the "heap" to avoid "stack overflow".
Pro Teaches fundamental OOP
Teaches you to leverage object oriented programming.
Pro Excellent compiler optimization
Both open source compilers (such as Clang and GCC), and proprietary ones (like Intel's and Microsoft's) are very good at analyzing program flow and program optimization. This is mostly due to the widespread usage of C/C++ applications running everything from mobile/desktop/server Operating Systems, to search engines and webserver software, and the demand for performance.
Pro Teaches problem solving
The great STL is the most powerful Data Structure and Algorithms Library. It would benefit you very much in problem solving, your main main way to love programming. The code is much compact compared to Java and C#. No unnecessary classes are in your way; yet when you need classes they are available unlike C. The code runs very fast.
Pro Teaches low-level programming, but doesn't have as many pitfalls as C
Teaches data types, low-level program flow and the so common C-style syntax while not being as much of a pain as C itself.
Pro STD is often updated
The functionalities keep growing throughout the years. C++11 gave us a soft type of garbage collecting with the smart pointers.
Pro C code can be used in C++ code
Most C code will work as C++.
Pro Faster execution of the same algorithms
Because C++ (and its precursor C) are "lower level" than a lot of popular programming languages they are also faster at executing code than Java or C# which require VMs and garbage collection threads.
Pro Universal, portable, best complexity/efficiency trade-off
Pro Best way to understand algorithms
Pro Has lots of library
C++ is mature and everything has standardized library.
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 Static module system
Elm uses easy to use modules.
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) )
module MyModule exposing (foo, bar)
Pro Growing community
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 Interactive Programming and Hot Swapping
Support for hot swapping and interactive programming is included.
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 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 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 Not quite Haskell semantics
Con Huge language gets in the way of learning
C++ is such an atrociously over-complicated language that its learning curve may get in the way of learning fundamentals. Learning C++ well is a ten-year project, and even experts are frequently surprised by the language.
Con Tough to learn as the first language
Many of the concepts are hard to grasp if you have no prior programming experience.
Con Undefined behavior
Subtle errors can render the entire program "undefined" by the complicated C++ standard. The standard imposes no requirements in such cases. Thus C++ compiler writers are free to ignore the existence of such cases and Bad Things are prone to happen instead. Even experts can't reliably avoid undefined cases in C++, so how can beginners be expected to do so?
Con Module system is not great
C++ uses the
#include mechanism provided by C. Which unfortunately is a poor way of accessing the API of a library. Some of the reasons why the module system is weak are:
Compile time scalability: The compiler must preprocess every header included in a file, and every header included in those headers. This process must be repeated for every translation unit in the program. As can be imagined, this doesn't scale very well. For each header added you are increasing the compilation time exponentially.
Fragile: modules included are treated as textual imports by the compiler. This causes all sorts of problems since they are subject to any macro definitions in the time of the inclusion. If any of these macro definitions collide with a name in the library it can break the library API .
Con No two programmers can agree on which 10% subset of C++ to use
C++ is such a huge and complicated language, that programmers have to learn a disciplined subset of it to reliably get anything done. The problem is, no-one can agree on which subset to use and they can't understand each other.
Con C++ succombs under its own weight
The years of cramped backward compatibility start to show in the syntax, complexity and very top-heavy language structures. Trying to keep up with far more elegant languages like C# doesn't do C++ any good either, because the committee always seems to be able to mess it up. After numerous years, still no modules... you must be kidding!
Con Retains nearly all bad habits of C
Con No reflection
C++ objects are frustratingly opaque. This makes debugging especially difficult, something beginners have to do a lot.
Con Memory leaks and segmentation faults
Because C and C++ allow the user direct access to memory and don't provide garbage collection threads, there is a probability that a program may have a "memory leak", which occurs when something a programmer allocated in the heap is not deallocated properly. Also, attempting to dereference memory protected by the operating system causes a segmentation fault and kills the program.
Con Arcane binding rules
Con Incomprehensible operator overloading resoution
Con After all these years of trying, still no decent string library.
Although you have several ways to handle strings, all of them are messy and error-prone, giving birth to many crashes and memory corruptions in the field. It's one of the worst languages ever, if you have to do strings.
Con Duplicates C features in incompatible ways
Arrays, strings, pointers, etc. have both C and C++ versions. Sometimes the C++ versions are worse. This is more useless trivia beginners have to sort through.
Con Bugs easily corrupt the memory you need to find them
You can usually get a core dump, but often the call stack gets completely overwritten. Compilers are not even consistent in how they map the binary objects to code.
Con Painfully slow compilation
Beginners need fast feedback
Con No way to locate definitions
No modules, just files, and no way to tell where anything came from.
Con Complicated types
Con Undefined behaviors and weak limited type safety
Undefined behavior in a program can cause unexpected results, making it hard to debug. With UB, program behavior may vary wildly depending on optimization settings. There are many cases that invoke UB, such as signed overflow, invalid dereferences, large integer shifts, uninitialized variables, etc. C++ allows for non-type safe operations such as logic errors, wild pointers, buffer overflow, etc. UB and type safety issues create a large number of bugs and security vulnerabilities.
Con Standard library missing important features
Con Exceptions incompatible with C++ manual memory management
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 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 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 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 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.