Thanks for the post Robert - it’s good to hear a variety of views on the topic and I am sure many people will find your post very interesting.
Btw, in case others haven’t twigged yet, @rvirding is Robert Virding, one of the creators of Erlang 
AstonJ
1
michalmuskala
I find the real power of using binaries for strings in pattern matching.
It’s very easy to distinguish a list of strings from a string, while with
charlists it’s rather difficult.
I admit that the syntax of Erlang is extremely simple and quite easy to
pick up (besides punctuation). There’s always the trade-off of
expressiveness vs simplicity, and I feel like which one is better is a
question of personal preference more than anything else.
I also agree with Robert, that macros are a great feature you can easily
use to shoot yourself not just in the foot, but straight in the face. And
unfortunately I see many libraries in Elixir that heavily overuse macros
for things that could be easily solved with regular functions. That happens
especially frequent with the use syntax that is often used to simulate
inheritance (in terms of OO). It’s important to remember the first rule of
the macro club: “Don’t write macros!” (not sure where that originated).
I’m surprised nobody mentioned protocols yet. To me it’s a very important
feature especially when it comes down to encoding/decoding between formats.
I find it quite powerful that I can define how to convert something to JSON
or that I can call the JSON encode function and not care what data do I
get. It’s a perfect example of extensibility of code for changing
circumstances - one part of the system only knows it deals with something
that can be encoded to JSON, what it is exactly and how to encode it is
maintained elsewhere.
Another feature of Elixir that was mentioned very briefly is the
consistency of standard library. While I understand the reasons why
Erlang’s stdlib is not consistent (backwards compatibility and stuff), it’s
still a great thing that all the collections have a put/3 function to
insert data or delete/2 to remove and that the order of arguments is
exactly the same. Or that predicates for use in guards are called
is_something and those that can’t be used in guards are called
something?.
To sum it up: whether it’s Elixir, Erlang or LFE I think that the more
people use either one, the more we all benefit, be it by the common
libraries we all use or the increased “recognizability” of the platform. We
shouldn’t strive to isolate those communities from one another, but to
bring them closer and encourage the exchange of ideas.
13
rvirding
Creator of Erlang
Let’s see if this reply works as I hope, first time.
Oh yes, there are many issues in choosing a good data representation. My point was just that saying that binary strings are better is not really saying very much.
As you point out binary strings generally use less memory than list strings: 1-4 bytes per character for binary strings vs 2 words per character for the list strings. However list strings are often faster as there is less copying and lists are optimally implemented.
If you are working with UTF-8 encoded characters then random access doesn’t work with either representation.
In both cases on the erlang-VM you are basing them on another datatype, lists or binaries, to implement them so it can be ambiguous what your data actually is. In the erlang shell lists of integers which can be strings are printed as strings even if that is not the intent. In elixir binaries which could be UTF-8 strings are printed as strings. Often this is correct but sometimes it can confusion. Try doing [97,97,99] in the erlang shell and <<97,98,99>> in the elixir shell. There is no way around this.
Probably the best way is to mix implementations: use lists for the string parts you work on and binaries for the rest. But there is no built in support for this.
In erlang we chose lists as this was a common way of doing it in the functional world while I guess José chose binaries as this was closer to what Ruby and other languages do.
It boils down to choices. “Pest eller cholera” as the swedish saying goes.
5
rvirding
Creator of Erlang
Hehehe, another rule on macros I have heard is “Don’t use a macro when you can use a function”. 
Yes, the libraries are a problem. People complain, quite rightly, that they are inconsistent but if we then say “ok, we will fix them” they complain even more. And doing things like having new versions, for example lists2, is even worse. This I am a bit jealous that elixir could do that.
We have occasionally had these OO drives for erlang as well but they have usually gone away after a while. Although we had an experimental parametrised modules for a few versions which was very OOish.
6