Quick post while I have a minute.

1. Immutability means that the code is easy to reason about, test, and if done properly, much easier to read. You have no surprise hidden mutation of state in random calls. You have no worry about how a variable is going to change as it is called. The program is easy to follow and read.

2. Elixir is built on the EVM/BEAM, if you want to build something for the web, network processing, or as a glue it is unparalleled, you will not have to worry about significantly optimizing your code later as you may need to in any other language. Immutable function programming means you build things up via functions to transform data as it flows through the program, wonderfully simple and expressive without tons of cruft.

3. As an aside, when not to choose Elixir, if you want to learn functional typed programming, something like Haskell will ‘teach’ you better than almost any other language, however OCaml will be the best if you want to write to ‘get stuff done’ (that does not involve massive scale, OCaml has a GIL like Python does (though being fixed later)) at a low level as OCaml is ‘fast’. But as always, for web or scaling, anything on the EVM is pretty hard to beat.

4. Alternatives: There is a growing language on the EVM called alpaca, it is still early and young but it is a typed functional language on the EVM, interoperates with Elixir and all.

5. Notes: LISP/Scheme is not functional, is as about as imperative as it gets by default, and with libraries/macros it becomes anything.

In a way i am asking whether a functional programming language is a better way to program

Not in general, no. Functional programming has its advantages as well as its disadvantages. Listing advantages of functional programming in this forum feels like preaching to the choir, so just to give you a vague idea of where functional programming is just ill-suited, consider dynamic programming algorithms or other algorithms where the most straightforward (and efficient) solution involves continuously modifying an array.

Programming paradigms and languages are tools, not religions. Try them out, gain experience, extend your toolbox, then choose the right tool for the job.

Unless of course you use LFE, Lisp Flavoured Erlang, which is not imperative and behaves like Erlang and Elixir.

If you really don’t care I’d actually not start with Elixir since there is a lot to learn that you just wouldn’t need (Erlang and it’s tools are mostly about concurrency).

Though if you program professionally, chances are sooner or later you will have to do something web related or distributed (even if you’ll have one server with few cores) and that’s where Elixir shines.

Yes, there just is nothing preventing you from doing it all the time. This makes certain things a lot more easy (such as doing IO and working with randomly generated data). This means that Elixir has a lot less steep learning curve than e.g. Haskell, at the expense of some flexibility that Haskell’s pure abstraction layers can provide. In Elixir, functional programming is a means while in Haskell it is an (the?) end itself.

Working with state is a lot harder in a pure language, because this involves Monads, which are considered one of the harder to understand concepts, if only because they are so abstract that it is hard to write a guide about them that works for everyone. I would definitely consider it to be one of the most important tools to understand for programmers especially because they are so generalizeable, but this definitely takes a lot of time and effort.

Writing code that happens to be pure is the easiest to reason about and, at least in my opinion, usually the most idiomatic way to solve a problem. If you want to keep as closely to the ‘pure functional’ ideal as possible, just don’t perform any side-effects in your functions, except at the outermost layer(s).

About using Elixir’s concurrency model: You don’t need to work with it, nor understand it, when starting out with Elixir. At some point you will start writing code where it makes sense to split certain parts of the computation or state-keeping off to a separate process so multiple things can happen at the same time, but it is important to never forget that the main unit of code organization in Elixir is not a Process, but a Module.

So: You’ll cross that bridge when you come to it. For many simple tasks, you can use Elixir perfectly without using the concurrency model directly. The code you write will still be faster than interpreted languages (Ruby, Python, …) because Elixir compiles to bytecode, and more readable / easier to understand than when using a systems language like C, C++, Rust. Yes, e.g. Haskell might compile to even faster, native, code, but learning it comes with a steeper learning curve and the documentation is not as good/readable/extensive/accessible as Elixir’s (I think these arguments can also be made for OCaml, but I’ll refrain from doing so because I have no personal experience with it, and @OvermindDL1 might lynch me ).

Switching to a functional language will most importantly give you the benefit of referential transparency which makes your code a lot easier to maintain than object-oriented or imperative languages.