Learning Elixir & Why Functional Matters
With the challenges facing Ruby and Rails, many are finding Elixir as a good alternative, especially considering performance and concurrency.
But this isn't just because it is somehow faster--while it is more memory efficient, better with streams, parallel processing and concurrency than Ruby the gains are actually simply in the functional paradigm, and that it creates more efficient and less buggy code.
Ultimately, learning how to program functionally will make you a better programmer. So even if you don't use Elixir in your daily work, learning
it as a language will give you experience that can help you even in your non-elixir programming!
Functional vs Imperative
The gains are fundamentally about functional programming, which is different from imperative programming (the latter being what most scripting and OOP languages are, including Java, Python, C, etc).
Even experienced programmers get confused over the semantics, so don't let it cause you pause if you aren't sure what the difference is. I will explain things at a high level, but there are better in-depth guides for explaining the value of functional programming. Furthermore, being 100% pure functional is actually almost unattainable, so don't stress about that either!
At a simplistic level, functional programs behave around immutable variables, which means you don't get any unexpected side effects. But programming is inherently about changing the state of something, so how do you change a variable that is immutable? By calling a function, of course.
There are a variety of discussions about the differences, but at a high level functional languages help make faster and less buggy code, because of their inherent nature, which includes:
- Functions calling functions (and recursion is important)
- Immutability
- Avoiding side effects to your data
- Very Parallelizable
If you understand what the difference is between the stack and the heap, then one way to think of functional languages is that there is no heap. You cannot create nor use shared memory. Everything is allocated on the stack (within the function's memory space, as it were) and after the function exits, everything is implicitly reaped back in.
Now consider how that would work with objects, or nested dictionaries in other languages... and how often data changing unexpectedly (see #3 above) has caused you hours of painful debugging. These data structures are stored on the heap -- outside of the stack, meaning separate tedious and painful to handle processes must then exist to manage that heap memory (i.e. "garbage collection"). Not to mention that if any other function can touch this heap memory and mess with things, you have a hard time being confident if it was changed properly or not -- thus the common bugs.
From this vantage point the functional paradigm begins to show its value fairly quickly, on memory safety and accidental data changes alone.
Exploring Elixir
To help people explore possibilities with Elixir, I've gathered some information together.
Elixir looks a lot like Ruby, by design, but it runs on top of the Erlang beam, which has existed for some time--this has influenced its behavior and concepts, to a degree. This also means there are some packages that can be leveraged across both platforms.
Useful info:
- Learning Elixir made me a better Programmer
- Elixir for Rubyists
- Elixir the New Wave?
- When to use Elixir vs Ruby/Rails
- Language Constructs are different:
- Iterating is different
- Pattern Matching is a very powerful polymorphism - think of it as describing how you want to see your data before the function is called, rather than poking and investigating the data after it arrives to decide if you like it's shape.
- Phoenix rather than Rails
- Phoenix for Rails Developers (book)
- Understand Elixir Processes - how to leverage the power of Elixir's concurrency.
- Understanding Supervisors
- Using the system:
- Who uses Elixir?
Courses
- Pragmatic Studio's Elixir (first few sections are free)