I was quite surprised by how amicable and positive this blog post was; I expected him to have lots of objections. It's admirable that an old hand like Joe Armstrong can be so open and accepting of something that essentially sets out to improve on his lifework.<p>In fact, if you look at his paper on the development of Erlang [1] while at Ericsson, which is coincidentally a juicy, fascinating read, Armstrong is being very forthcoming about the struggle to develop the language, in particular developing a good syntax, and also very forthcoming about the involved parties' lack of experience with language design; in particular, the Prolog-like syntax seems less of a planned decision than a side-effect of the first implementations being written in Prolog itself, and following the path of least resistance. Also, it worked.<p>At any rate; it seems clear to me that Armstrong values the principles behind Erlang's <i>design</i> (concurrency, immutability, fault tolerance and so on) more than the actual syntax. I wonder, at this point, how amenable he would be to larger syntax changes to Erlang itself, or if he is happy with the fact that Elixir is a completely separate project.<p>(There is something weird about the effusive tone and surreal humour in the blog post, though. Is this his new "Erlang evangelist voice", or has he always been writing in this way?)<p>[1] <a href="https://docs.google.com/viewer?url=http%3A%2F%2Fwebcem01.cem.itesm.mx%3A8005%2Ferlang%2Fcd%2Fdownloads%2Fhopl_erlang.pdf" rel="nofollow">https://docs.google.com/viewer?url=http%3A%2F%2Fwebcem01.cem...</a>
A precursor to Elixir, Reia, got me interested in Erlang. After having written Erlang for a little while now, I'm not sure of the benefits of a language like Elixir or Reia anymore (which seem mostly focused on improving syntax). Sure, Erlang syntax is odd starting out, but you get over that very quickly.<p>I can't help but compare it to CoffeeScript. Sure, CoffeeScript papers over some inconveniences of JavaScript, but at the end of the day I find myself writing JavaScript in a disciplined way instead of reaching for yet another abstraction. I realize it's not a good comparison as CoffeeScript compiles to JS while Elixir and Erlang both compile to a shared VM (BEAM), but I don't think Elixir has added enough new ideas to warrant focusing on it in favor of Erlang, yet (for me at least). That may change in time.
It was very enlightening to see one guy who created a language go over someone else's language. The point about versioning source code files is interesting: you can tell Joe would like to be able to make some changes to Erlang itself without worrying about all those lines of code out there in mission critical deployments. Great read, in any case, for anyone interesting in language design.
I generally like Elixir approach, but find that in many cases it's more verbose than standard Erlang syntax.<p>I like Erlang way of using lowercase for atoms and uppercase for variables, in Elixir they use ':' sigil to denote atoms like in Ruby, this makes code much more verbose, since atoms are widespread in Erlang and also used for module names.<p>Elixir should take good parts of Ruby, not sigils, which are inherited from Perl. They are the reason I dislike Ruby's internal DSLs, b/c they are not English, but English with sigils.<p>If possible I would get rid of commas, I.e. [1 2 3] instead of [1,2,3] .<p>I agree about f.() being ugly. if function names were lowercase and variables uppercase - there would be no need to introduce new fun call syntax.<p>Also agree about docstrings moved inside the functions (like in Python and Clojure). Same apply to dialyzer typespecs.<p>I think single assignment should be default, but there are should be way to explicitly override it, i.e.:<p><pre><code> a = 1
a = 2 - bad match, but
'a = 2 - ok</code></pre>
This is great timing. We just recorded a two hour Intro to Elixir with its creator Jose Valim. We'll be publishing it in June at <a href="https://peepcode.com" rel="nofollow">https://peepcode.com</a><p>I think it will be a good companion to the books from Pragmatic Programmers and O'Reilly. Jose works through a real-world project. You can see how he writes code with Elixir, uses metaprogramming, converts code to run concurrently, etc.<p>I was impressed with the syntactical consistency that makes more sense than Ruby, such as putting "do" after "def". You can write native-looking structures in Elixir that wouldn't be possible in Ruby (such as an if-then).
Very good, it's great to see Elixir is aligned with what Joe's vision of good practice and how things should evolve. This can be the start of something that will help both sides, we will follow what will happen.
As someone who ever wanted to learn erlang but didn't like the syntax, i'm hoping elixir will do it easy for "non-functional" programmes to enter the world of erlang.
I love visually distinct/suggestive operators so long as they're easy to type on a standard layout. So for that reason alone I agree that a ! b is better than a <- b<p>With many punctuation infix operators (see Scala for an extreme case) people who don't use the language won't understand the code, and you'll have to use an appropriate search engine or emacs mode to look up docs, but it's worth it for what you get in exchange.<p>It would be nice for the community to standardize on unicode glyphs for enhanced visual representation of ascii-art operators like |> <- etc. (so that online syntax highlighters / code review / diff interfaces show the same as your editor). Pretty glyphs instead of mere ASCII could really help readers (the source code should still be ASCII).
Every time I see <i>"Elixir"</i> used in reference to software I'm reminded of Xerox' Elixir circa 1993, when I was forced to learn how to use the proprietary interface - this was before Windows support had been integrated.<p><a href="http://www.outputlinks.com/html/people/Entrepreneurial_Spirit_Basit_Hamid_WYSIWYG_Visionary_and_Elixir_Technologies_Founder_112205111000-639290214.aspx" rel="nofollow">http://www.outputlinks.com/html/people/Entrepreneurial_Spiri...</a><p><a href="http://www.xerox.com/digital-printing/workflow/printing-software/elixir-design-pro/enza.html" rel="nofollow">http://www.xerox.com/digital-printing/workflow/printing-soft...</a><p>We used Xerox Elixir to typeset forms pre-press for a Xerox DocuTech.
Lets hope that more of these changes make it upstream or that they modify the vm to make it easier for other languages to work on the erlang vm. Erlang has lots of potential but lots of people get scared away from the syntax and other oddities.
Joe's points are really good. This drives me crazy in Elixir:<p>iex(1)> f = fn x -> x + 1 end<p>#Function<erl_eval.6.82930912><p>iex(2)> f()<p><i></i> (UndefinedFunctionError) undefined function(stack trace trimmed...)<p>iex(2)> f.(1)<p>2
see also the discussion on lambda the ultimate
<a href="http://lambda-the-ultimate.org/node/4754" rel="nofollow">http://lambda-the-ultimate.org/node/4754</a>
<i>Gut feeling precedes logic. I know when things are right, I don’t know how or why I know, but the explanation of why things are right often comes weeks or years later. Malcolm Gladwell in his book Blink: The Power of Thinking Without Thinking talks about this. Experts in a particular field can often instantly know that something is right, but they can’t explain why.</i><p>Funny, no one talks about the <i>other</i> phenomenon. The one where experts think things are right and then they turn out not to have been. I guess that phenomenon just isn't as interesting.<p><a href="http://en.wikipedia.org/wiki/Confirmation_bias" rel="nofollow">http://en.wikipedia.org/wiki/Confirmation_bias</a>
<a href="http://en.wikipedia.org/wiki/Cherry_picking_(fallacy)" rel="nofollow">http://en.wikipedia.org/wiki/Cherry_picking_(fallacy)</a>
Makes me cringe to hear someone say `|>` is the `pipe operator`.<p>If you're thinking operators your probably doing it wrong in functional programming.<p>It's simply another higher-order function that enables function composition. g |> f = λx → f (g (x))<p>edit: My reasoning might be really flawed as I have no idea if erlang/elixr can define functions that look like `operators` and therefore don't know if `|>` is built in. Yet, you shouldn't assume |> is some magical thing, but respect it as a higher-order function in my opinion.