Thanks jerf for your feedback even though it was based on rapidly reading the document. I will address a few things: 1) In general I am trying my best to not c

Thanks jerf for your feedback even though it was based on rapidly reading the document. I will address a few things: 1) In general I am trying my best to not change the syntax for Erlang data structures. Atoms were one of the few exceptions due to the grammar. I chose to go with the lisp syntax (and similar to Ruby :symbol). But indeed I could have chosen it to be apos-delimited at all times to be closer to Erlang, I have to think more about it. 2) head and tail: good point. The reason they are there though, is if you need to dynamically dispatch a method to retrieve the head or the tail. But in general, I don't think we should limit the language to avoid people writing bad code. We can better solve this problem with good docs (therefore I have removed such bad examples from the README). 3) Empty lists being considered false: I was not sure at the beginning if they should evaluate to false or not but after your feedback I have decided to change so just false evaluates to false. Although in some cases it if feels very weird that a proper nil is missing, for instance Object.__parent__ returning an empty list that evaluates to true feels weird. Maybe I should add nil down the road. 4) "Merely tweaking Erlang" can you give examples where we may be merely tweaking Erlang? 5) case/match: I borrowed the syntax for Ruby and yes, Elixir is not whitespace sensitive. In Ruby, people indent case/match in both ways, I am particularly fine with both. 6) try/catch: yes, I also would like exceptions to be objects (like Python and Ruby). However, the fact I cannot easily have custom guards in Erlang makes that considerably more complicated to implement. Maybe we can add it in the future if more and more people start to use Elixir enough to justify putting a lot of effort in complicated features. 7) String interpolation: I am not aware of such issues. If you could point to more references or discuss it better, I would really appreciate it! 8) The inlist is because we need to make a difference between list and binaries when there is an ambiguity. So what exactly do you propose? To always be explicit here (using inlist or inbin)? Notice that this is an Erlang limitation, the Erlang syntax uses <- and <= to make a difference between them both. 9) Method visibility: hrm, you are actually right. I could have started without this feature and have added it if I eventually needed it. We need the private methods (because they map to local not-exported methods in Erlang) but protected methods could definitely be gone. 10) The GenServer example is not missing, it is in the examples/ folder (too long for the README): https://github.com/josevalim/elixir/blob/master/examples/gen_server.ex https://github.com/josevalim/elixir/blob/master/examples/gen... Elixir has also Code::Server (that stores your load paths) and ExUnit::Server (that stores your test cases) that could be used as examples. GenServer in Elixir is very OO'ish and I am particularly happy with the current implementation after going through a few iterations. Writing Elixir has been an extremely rewarding experience and reading your feedback makes it even better. Thanks again for sharing and I hope you can eventually use it and help us improve it more!