Because with more expressive constructs, you may find not having to write list[ix] very often. For example, a traditional "for" loop may be replaced more succinctly with an operation such as "Enum.map" or "Enum.filter" [1]. Data transformations made more obvious.

Coming from imperative languages especially (speaking for myself), have to re-think/re-learn how you write code, but it does end up being a worthwhile investment

[1] https://hexdocs.pm/elixir/Enum.html

I want to beleive that, but I don't know. For example, in Elixir, you would write something like this to square a list: 'Enum.map [1,2,3], $($1 * $1)'. In Ruby: '[1,2,3].map {|e| e * e}'. The Ruby seems more natural to me, but maybe it's the years of OOP speaking and not reason.

Btw, there are a number of ways to write that expression depending on the complexity of the function

Short syntax:

   Enum.map [1,2,3], &(&1 * &1)

Long syntax:

   Enum.map [1,2,3], (fn num ->
     num * num
   end)

Or even:

   square_me = &(&1 * &1)
   Enum.map [1,2,3], square_me

   square_me_too = fn(num) -> num * num end
   Enum.map [1,2,3], square_me_too

Defining a function separately (e.g. even in another module) and referencing it:

   def square(num) do
      num * num
   end

   def doing_something() do
      ...

      Enum.map [1,2,3], &square/1
      Enum.map [1,2,3], &SomeOtherModule.square/1

      ...
   end

yeah and in Ruby, you can do:

    class Array
      def square
        map {|e| e * e}
      end
    end

Why storing code in a seperate module is a superior way than storing code in its class?

You've now altered a global object which other code may rely on. Indeed, you may overwrite someone else's Array#square method (or have yours overwritten). As a separate module, the additional code is logically distinct. You can find many discussions about monkey-patching elsewhere. It's not my intent here to argue one way or the other, just to answer your question as to why one may choose package the code as a separate module.

If it is to be reused by other modules, or if it is complex (and likely itself needs to be split up into smaller functions)

Think of:

   items = ["file_a", "file_b", "file_c"]
   Enum.map items, &HelpfulDownloaderModule.download/1

download/1 is probably pretty complex and/or can be of use in other pieces of code.

Ive been studying functional languages for the most part of 2017 and the first example makes more sense to me.

Because it's not superior, not on its own. You need context to tell which one is better. Not to mention that you look too closely, so you miss higher-level design that makes the difference between functional and imperative languages.

Can you provide a minimal example where functional clearly overtake oop?

Bad oop is clearly inferior to good functional. ie React. But if OOP is able to do functional as well, shouldn't OOP win on the long run?

I think it's also about the ecosystem. With Elixir all third party packages etc. can be relied on having no side-effects / immutability.

If you try to code functional in an OOP language, you would have to make sure that no third party modules (or coworkers accidentally) write code that "misbehaves" in such aspects. Just like you currently have to make sure that the Ruby code you use is threadsafe.

With immutability you gain all those features baked into Erlang/OTP (scalability, reliability).

When coding moves from science to art.

Elixir lists aren't index based arrays. They're linked lists. If you Google around there are some good forum posts explaining the difference.

Beside pattern matching - that I agree is awesome - is there anything else that make Elixir approach superior to Ruby one?

I am functional newbie too but with

`List.get_elem` you can write an higher order function `List.get_Nth_elm` which takes `List.get_elem` as an agrument .