> This doesn't have to be and "either one choice". The great think is both of them live on the wonderful BEAM VM. They both can take advantage of a completely c

> This doesn't have to be and "either one choice". The great think is both of them live on the wonderful BEAM VM. They both can take advantage of a completely concurrent garbage collector and all the other goodies. Some modules can be written in Erlang some in Elixir. Indeed! > Elixir it seems very easily can call Erlang functions. I don't know about vice-versa though. Vice-versa is also true. :) Given you have an Elixir module called String, you can it from Erlang as: 'Elixir-String':upcase(<<"fin">>) I agree 'Elixir-String' is not the prettiest sight but this is because Erlang had an experimental feature called packages that forbade us from using 'Elixir.String'. Luckily, this "feature" is being removed from R16 and in the future you should be able to simply call 'Elixir.String'. There is more information about integration with Erlang in the crash course: http://elixir-lang.org/crash-course.html http://elixir-lang.org/crash-course.html > Choosing a default value of nil seems arbitrary. nil would be an arbitrary choice if you look only at 'if'. But if the language constructs and the standard library consistently uses nil, it is coherent. In Erlang, not having a matching if raises an error, accessing an unknown key in process dictionary returns the atom 'undefined' and accessing an unknown key in a dict returns the atom 'error' or raises an error (depending on the function you call). In Elixir, they would all return nil. This is extremely important, because it allows you to create conveniences around nil, like the operators && and ||.