I’ll start with something that is fresh in my mind - the opening chapter (and preface) to Programming Phoenix

It made the hairs on the back of my neck stand up!

You can read both the preface and the introductory chapter for free!

Here are some of the topics it covers:

• Rails Developers Seeking Solutions
• Dynamic Programmers Looking for a Mature Environment
• Java Developers Seeking More
• Erlang Developers Doing Integrated Web Development
• Heat Seekers

And…

• Speed
• Concurrency
• Beauty
• Simple Abstractions
• Effortlessly Extensible
• Interactive
• Scaling by Forgetting
• Processes and Channels
• Reliable

Obviously these are with Phoenix in mind - but then, Phoenix itself is the perfect tech to showcase the draw and power of Elixir

If you’ve not read these chapters you are truly missing out!

Read them for free here:

• Read this first
• Then read this

The main reason for me to love Elixir (and use it in Production!), is that Elixir is built with developers in mind:

• In Elixir, the way to maintainable code usually coincides with the path of least resistance. (in many other languages, the path of least resistance would result in duct-tape solutions everywhere).
• Elixir and most of its libraries have top-notch documentation.
• Elixir has one of the best testing-stories out there.
• Did I mention that hot-code-reloading is a lot of fun? ^.^

And secondarily, the ability to reason about concurrency and distributed systems by using the BEAM’s implementation of the Actor Model and supervision trees means that:

• The parts of the system that depend on one-other and have to execute sequentially are made explicit.
• The parts of the system that cannot function without one-other are made explicit.
• Failure-handling is set up, such that the system is able to restore to a prior consistent state, and able to provide partial functionality until the system is repaired.

Why are you using (or loving!) Elixir in 2018?

• Power of Erlang (functional, BEAM, OTP).
• Joy of Ruby (friendly syntax, Phoenix framework).
• Pipes (Believe me or not, Elixir helps me write better Ruby code as well, as ‘transforming data’ really makes me think in better intent to separate codes into more approriate subroutines, I no longer writes tons of codes in a single subroutine in the first try, Rubocop and Credo make more sense to me now).
• Optional typespecs.
• Developing Phoenix Framework app is crazy fast, tests run like F1 racing cars. If you code Rails before, you know this is a game-changer.
• Not specific to Elixir, but FallbackController in Phoenix is really nice to have.

Which resources do you recommend that do a good job of highlighting the benefits of Elixir?

Every videos from Elixirconf.

Learning to write Elixir has felt a bit like gaining a superpower.

So far, multi-clause functions and recursion-related micropatterns have helped me come up with simple solutions to otherwise difficult problems.

Aspirationally, I like the idea of quickly building things that both just work and that can scale far beyond what I could figure out in another language.

This is also another superb resource, it covers the story of Elixir while highlighting many of its uses…

I would really love to collect some thoughts on this too so I can help companies not be afraid to adopt Elixir.

My big draws are Maintainability and Scalability

Maintainability

I watched the micropatterns talk, and Cameron really helps put to words the enjoyable parts of Elixir for me.

The quote from Scott Wlaschin was really insightful as well:

OOP has objects in the large, and methods in the small
FP has functions in the large, and functions in the small

What I take this to mean is that you attack small and large problems the same way in FP and Elixir, so problem-solving approaches are generally very consistent. For example, since Elixir is immutable, functions will transform data instead of leveraging state mutation where you can call a method on an object, and the object changes itself and/or other objects or their state that may not be in the same context of the developer. Over time all these OOP side-effects are forgotten and it becomes “less maintainable”. I don’t have to shift my problem-solving paradigms from “methods” to “objects” when it’s time to scale the solution.

Another point I thought was really helpful is that Elixir and pattern-matching tends to help developers architect for happy-paths. I’m not very familiar with railway-programming, but the idea that I’m gleaning from it so far is that we want to develop for the happy path, and tend to forget the unhappy paths, which is where our bugs usually show themselves. In Ruby, I usually encounter this as NoMethodError and always handling nil which makes it harder to grok the code.

def (%Employee{manager: %Manager{} = manager} = employee), do: happy_path()
def (employee), do: unhappy_path()

This is a simple example, but I could add more pattern-matching clauses to help me report better errors, or redirect the unhappy path to another process to make it happy.

Lastly about maintainability, because the Elixir community generally frowns upon meta-programming, you encounter less DSLs which are layers of misdirection. Rails is a huge DSL, so knowing Rails isn’t the same thing has knowing Ruby; knowing ActiveAdmin isn’t the same as knowing Ruby, but Plug is just elixir functions.

I think this leads itself to Elixir codebases generally being more maintainable. Would others agree? I feel that way so far, but I don’t have any psychology or data to prove that yet or make a point.

Scalability

My approach to creating software to solve a problem usually starts with having an idea for a solution. That solution starts small, but then as I dig into it, I realize it’s more complicated than I imagined, and that I might want to solve other domain problems at the same time.

If I chose something like Rails, I would have this feeling of impending doom that my app will get slow or is already slow, and then I’ll have to spend some time in devops to solve that problem; I’m not interested in devops like I am creating software. Whether that feeling is true or not is a different conversation-- I just feel that. I’ve also experienced issues forcing me to optimize old Rails code because it allowed my coworkers and I to be lazy with our SQL queries and architecture. If this app is commercialized, the company with that solution now has to determine what it has to do in order to keep growth going in order to meet goals. The question always comes up, “should we do a rewrite?”. A rewrite is rarely the right commercial answer, but developers at that point probably want to try new ideas in a safe place, and sometimes in a new language, so they’re really, really, really tempted to do a rewrite. A rewrite may the right professional development answer for that developer. Those opportunities don’t come often.

If I chose something like Elixir and Phoenix, I’ve never yet gotten the feeling of impending doom. I have felt the need to rearchitect some code, especially when Phoenix 1.3 released with DDD as a focus. But I felt like I had a safe place to try ideas when rearchitecting because everything’s a module with functions (see earlier point about maintainability).

The solution can start small, and I know that it can be scaled to enterprise scale. I no longer have to decide between a “productive language” or “enterprise language” when starting a project. I know this because it has concurrency out of the box, extremely good tools like mix, an incredible testing culture that’s also easy to test (since it’s all just modules and functions), and the base of a 30yr old language and OTP. And to boot, I can read Elixir just as easy as Ruby and understand the intention of the other developer.

summing up,
not all of these points I make are unique to Elixir-- you can find pattern-matching and immutability and great ecosystems elsewhere, but the magic is that the sum of all these small things build up to a greater language and ecosystem.

It’s a really long topic … Everything start long, long ago … no wait … sorry (bad template).

To not make this comment too big I would just list my few hints, so everybody could find himself/herself more and more things:

0. Of course nothing bad happen, so all things that we loved in previous years
1. Review all erlang/otp changelog files since last thread like this one
2. Review all elixir-lang/elixir changelog files since last thread like this one
3. Browse all topics in #your-libraries-projects section
4. Browse as more as possible (yeah we already have tons of it) libraries in hex
5. Browse as more as possible (like in previous point) projects in Github, GitLab and other code hosting repository services
6. Look at our adoption and media including blogs, video blogs and even paid learning
7. Look how fast this community is growing and how much we help each other

and anyway you would be able to find even more cons in another ways …

It’s just already too hard to list all things why I and others love this fantastic language!

It comes to my mind: i read elixir code easy.
( one of the advantage comparing to other modern lang).

For large codebases is essential to don t have a barrier how the code is formatted and structured, this doesnt depend always from programmers
Pipelines operators ,etc and similarity to ruby which is one also one the most beautiful readable lang, make elixir just sexy to read ( i dont want to add tne other feat

I’m going to add this talk here too:

I’m using Elixir because it seems to me like a natural fit for the path I was going down as a developer.

Like a lot of us I started out in high school and college being taught Java and OOP. Once I graduated and got into the industry in 2015, the company I worked for was almost entirely .NET, and always with SQL Server.

That combination had worked for most of our projects (admittedly most of them are pretty simple CRUD apps), but being the millennial that I am I had to see what else was out there. Not like I didn’t like C#, I still think it’s a great language and the ecosystem is only getting better with the rise of .NET Core, but I just wanted to experiment.

So for the next year I went around chasing shiny objects and reading opinionated blog posts about why language X is better than language Y, but all the while never actually getting anywhere. I knew that I wanted to build better software, but all I actually got was a bad case of analysis paralysis.

Eventually I came to the conclusion that most languages were just different shaped hammers, all trying to solve a very similar problem in a slightly different way. So I just decided to focus my time on .NET (which my company was happy about) and for a while I was happy.

But then a project came along that was different from the rest, and i saw it as solving a different problem then the ones we had previously solved. So I ventured into the depths again, but this time I tried to stay as close to the .NET pond as possible, and eventually I found Orleans, which is an implementation of the actor model (sort of) developed by Microsoft Research. I had heard of the actor model before, so I decided to dig a little deeper. I went through all the Orleans documentation and tutorials I could find, and then eventually found Akka.NET, and I really liked what I found. Despite that, it felt like these frameworks were simply bolting on the actor model, and I wanted the real thing. So when on vacation this summer, I found an Elixir tutorial by Rob Conery (a seemingly reformed .NET developer turned Ruby and now Elixir), and went through it. And I gotta say, I am having a harder and harder time writing C# with every passing day. Elixir provides an entirely different way of solving problems, and I love that about it. Not only do I like writing Elixir code, but I actually feel like I am learning new skills instead of just learning another new syntax.

Elixir feels like the natural next step in my “Programming Progression”, and I’m really enjoying it. Keep up the great work!