This doesn't have to be an "either or" choice. The great thing 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.
Elixir it seems very easily can call Erlang functions. I don't know about vice-versa though.
A lot of things in the article are related to syntax. I agree that single assignment is not needed for concurrency and the if statement can just return a nil. This, I argue is a matter of preference. In a large system knowing that a variable you set could not have changed, makes state management more explicit, some might see that as a benefit.
Also if statements are actually expressions, they should return a value. Choosing a default value of nil seems arbitrary. Just add another clause to if. Besides you'd probably want to use 'case ... of' anyway in most place. Just because 'if' in Erlang matches with the same keyword from C, doesn't mean that both work exactly the same way.
Now with the records, yes, there has been talk about adding "frames" (the equivalent of dictionaries or hash tables in other languages). The developers are thinking about it and I believe in release after the next or the one after that we might see that.
Now one thing I am really excited about in Elixir is macros. The ability to create a DSL. That is what probably will get to start playing with it.
> 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:
> 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 ||.
> 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.
Quite right. When criticizing Erlang, I make it a point to always specify Erlang the language and never Erlang the ecosystem.
> Elixir it seems very easily can call Erlang functions. I don't know about vice-versa though.
It's trivially easy.
> Now with the records, yes, there has been talk about adding "frames" (the equivalent of dictionaries or hash tables in other languages). The developers are thinking about it and I believe in release after the next or the one after that we might see that.
Yep, and as soon as frames are in Erlang we can begin utilizing them in Elixir too for things like pattern matching within the hash structure. The great thing about Elixir is that we don't have to wait for the OTP developers to implement features that developers want.
Elixir it seems very easily can call Erlang functions. I don't know about vice-versa though.
A lot of things in the article are related to syntax. I agree that single assignment is not needed for concurrency and the if statement can just return a nil. This, I argue is a matter of preference. In a large system knowing that a variable you set could not have changed, makes state management more explicit, some might see that as a benefit.
Also if statements are actually expressions, they should return a value. Choosing a default value of nil seems arbitrary. Just add another clause to if. Besides you'd probably want to use 'case ... of' anyway in most place. Just because 'if' in Erlang matches with the same keyword from C, doesn't mean that both work exactly the same way.
Now with the records, yes, there has been talk about adding "frames" (the equivalent of dictionaries or hash tables in other languages). The developers are thinking about it and I believe in release after the next or the one after that we might see that.
Now one thing I am really excited about in Elixir is macros. The ability to create a DSL. That is what probably will get to start playing with it.