Of course, I tend to feel much more productive in Elixir than Erlang, and thus use Elixir way more often than Erlang directly, but I'm able to come at Elixir with a more Erlangy perspective and approach.

Erlang have pattern matching via function with same name and you can tell if it's a group of pattern matching with semicolon and period. But with Elixir you can't tell it's just def and end.

Erlang's:

-module(recursive).

-export([fac/1]).

fac(N) when N == 0 -> 1;

fac(N) when N > 0 -> N * fac(N-1).

You can tell fac(N) both are in a group of pattern matching cause ';' and '.'. The '.' denote the last pattern matching function.

Elixir:

defmodule Factorial do

    def of(0), do: 1

    def of(n), do: n * of(n-1)

You can't tell because there is no ';' and '.'. This is a trivial case but when your Elixir's module have a tons of function in it, this issue become relevant.

This is the closest Erlang equivalent:

   fac(0) -> 1;
   fac(N) -> N * fac(N-1).

fac(0) -> 1;

fac(N) -> N * fac(N-1).

Or is there a particular advantage to write it using guards?

I would also like to point out that Erlang has also very good support and has seen adoption in some very critical systems as opposed to CRUD web applications which is the main domain of Elixir. Most of Ericsson’s products use Erlang to a certain degree, there are a lot of banking systems and aviation systems which make use of Erlang as well, quite a few Internet companies use it to great success, and many more.

And by the way, the semantic meaning of “;” and “.” is an awful lot similar to their use in the English language, you are blowing it out of proportions. This is a trivial thing which you learn after a 10 minutes introduction to Erlang. For me, personally, if one has a problem understanding the meaning of “;” and “.” or learning a new syntax for that matter, I can easily conclude that I probably should not give that person any decision power in designing systems.

(Now, of course, when I see more "traditional" C/Ruby/Perl/Python/Rust syntax, I can't help but roll my eyes, but that's a slightly different subject.)

The Erlang VM is the engine. You can make a beautiful, sleek, aerodynamic rocket, but it ain't going anywhere unless you literally light a fire under its butt. It helps that BEAM helps the rocket go fast :)

Of course, you need some sort of structural piece to hold your engine and your aerodynamic skin in place, lest your rocket crumples itself up into a ball at launch. That's where OTP comes in: providing a robust structure for your rocket.

Last but not least, you need to launch it. Rebar and Mix work reasonably well as launch clamps in this really contrived metaphor. You also have exrm (or Distillery nowadays, I guess) that works as the VAB, in which your rocket is put together so it can be launched.

I personally consider Elixir to have fewer aerodynamic bumps and other sources of drag than Erlang itself, but that's just, like, my opinion, man. Obviously people will disagree with that, and that's fine.

The rocket analogy is a good one, too. What Erlang accomplishes is massive, and Elixir uses and benefits from all of it.

I don't want to downplay what Elixir accomplishes, either ... to use a SpaceX analogy, Elixir and its ecosystem are like the guidance systems and deployable struts that let you land rockets repeatably on a barge in the middle of the ocean. It uses macros to make solving problems with rockets easier and more widespread, and maybe it also increases our ambition because of it. (I'm thinking about projects like phoenix_pubsub especially Tracker, ecto, the 1.4 registry, etc).

"By the time the software engineering of a language gets in good shape, the language has become obsolete in terms of 'needed expressiveness'. [Therefore] in a 'Real' computer science, the best languages should serve as the 'assembly code' for the next generation of expression!" [1]

He then proposed the hypothetical question: "What should Erlang be an assembly code for?" [2]

I'm not sure if he knew about Elixir..

[1] https://youtu.be/fhOHn9TClXY?t=30m39s [2] https://youtu.be/fhOHn9TClXY?t=36m49s

Experience after designing and deploying systems that run 100,000 transactions/sec per box: don't bother with engineers that cannot achieve proficiency in Erlang. Elixir is a crutch, and not something you want to show up with in 400 meters hurdles race. You will look pathetic.

Erlang has its uses and Elixir has its uses. Dismissing Elixir's userbase as 'pathetic' is pretty rude and a disservice to a pretty incredible language. See the Discord article where they clearly demonstrate Elixir and Genstage are ready for production and can be used to write performant services.

I get that you really like Erlang and its quirks, but maybe there are more mature ways of expressing this love than calling Elixir users 'pathetic'.

I totally take your point that everything written in Elixir could be written in Erlang. That much is a fact. However, my point in saying they serve different uses is saying that better syntax in itself isn't nothing. If a language enables many people to grasp actor-based concurrency in an easy to understand fashion, can we reduce that to "just syntax"? I guess my point is that introducing syntactic clarity is in itself a massive feature that shouldn't be dismissed.

I hope that further explains my intent!

And to answer your first question, although I thought I was very clear that I do not want to take part in your discussion with the parent: no, I do not think that you are a bad programmer for learning Elixir, I think if you were to only learn Elixir, call it a day, and then spread the word of how incredible Elixir is, you would be, however. Programming languages are just that, programming languages. The more you know the better and there is no silver bullet. As you will get back to Haskell you will probably come to appreciate its powers. Also, the fact that you have not grasped Haskell’s syntax when you have first tried does not make it a poor functional programming language and it certainly does not make Elixir a better designed functional programming language. That’s just your perception because Elixir was, for you, easier to learn. The fact that I cannot comprehend particle physics does not necessarily make particle physics a badly designed model.

But where would you stop?

If Elixir makes it easier to write fast, concurrent for many people than Erlang, that totally can be discussed. The way you separate developer satisfaction/well-designed syntax from the VM it runs on top of is a separation I dispute.

Obviously these comparisons will never be 100% valid, but I think they make my point: Will you say that Scala is no different (or better) from Java? Will you say that Dart or Elm are no different (or better) from JavaScript? Simply because their underlying architecture is the same?

I think there is some hostility I am sensing from Erlang programmers where there is none given in return. I don't hate Erlang. I'm simply saying a language that can leverage the performance of the Erlang VM shouldn't be dismissed. Again, I never ever said I thought Elixir was better than Erlang. I was just responding to the parent commenter's assertion that all alchemists are pathetic.

Also, I think the implication that may have entered my writing was that because I personally found Elixir easier to learn (and it would be difficult to argue that I am alone in this), it is somehow a better language than Haskell, Erlang, and many other FP languages out there. If that was the implication you drew, I apologise for my a mistake in my writing. Since I learned Elixir, I'm now taking a course in Haskell at my college to better understand these programming languages. Just because I called Elixir incredible, doesn't mean I believe it's the end all be all language!

Again, thanks for your comment. I learned a lot from it.

You misunderstand me. I did not say that Elixir is not different from Erlang, what I said already two times and this is the third time is that you cannot send me to some case study about how code deployed on the Erlang virtual machine performs well at high traffic and imply that the performance seen is a quality of Elixir, because it is not. Can we agree on this? That is the one and only point that I was trying to make, and if you read carefully and want to understand I think I have expressed that thought in a quite clear way. It is also a very factual truth, not a subjective matter, when we discuss syntax preference we do not discuss throughput because throughput is not a quality of the syntax. Even less so in the case of Elixir which runs on top of the Erlang virtual machine. Performance could be discussed as a function of syntax if, for instance, Elixir compiled to virtual machine instructions for the Erlang virtual machine and then had its own layer of optimizations etc. and then there would be some inherent quality of the Elixir syntax which makes those optimizations easier. But the fact of the matter is that Elixir compiles to Erlang which is then compiled to instructions for the virtual machine. Yes, Elixir it’s just syntax, I suggest you read its source code and not take my word for it. There is nothing incredible that Elixir has invented, it just looks like Ruby which made it easier to read by ex-Ruby programmers, that’s all.

Yes, of course I am biased to have a problem towards Elixir programmers making extraordinary claims when they lack cultural knowledge and brag about things that have not been invented by Elixir in any way but are qualities of a system which they very much enjoy criticizing in ignorance. I have even heard Elixir programmers talking about a so-called Elixir virtual machine which I find amazing and tells me a lot about their community and culture.