Except that “rockets” built with Erlang have been aerodynamic, production-ready, and deployed some 20 years before Elixir has even existed and they are still in use today. They did not start breaking off and, yes, they actually went to space, as opposed to what you imply in a very sneaky way in your first statement. If you want to be fair, you can say that Elixir is another skin of Erlang, the other way around does not hold.

That's exactly what I said, though: "There are other skins, though, like LFE and Erlang itself".

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.

There’s also “Erlang the Movie”; the designers of Erlang demo some of the qualities of the Erlang system in a delightful way: https://youtu.be/xrIjfIjssLE

Unrelated to your discussion with the parent, but I just wanted to point out that the fact that a system which was implemented in Elixir and runs on the Erlang virtual machine is able to sustain that traffic (and here I am referring to the link you posted) is and should be regarded as, largely, a quality of the Erlang virtual machine, and only to a very small extent to the programming language that it has been implemented in, if any at all. The fact that a system implemented in Elixir can sustain a large quantity of traffic while running on the Erlang virtual machine does not prove much about Elixir itself, other than the fact that it’s usable; you can implement the exact same system in Erlang also, or any other programming language for that matter. There is no inherent quality of Elixir itself that makes programs handle large amounts of traffic. That’s a quality of the Erlang virtual machine; Elixir is just syntax.

Thanks for your clarification. I think 'just syntax' is a bit dismissive of the importance that well-designed syntax has on being able to reason clearly in a certain way. Elixir's "just syntax" has made it so easy for me to understand FP concepts like pattern matching and higher order functions. I've struggled with these concepts before while trying to learn Haskell, Erlang and many other FP languages. Does that make me a bad programmer? The parent commenter would certainly think so.

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!

My point was not that everything which is written in Elixir can be written in Erlang but mostly that using a reference to a system that sustains a large amount of traffic which is implemented in Elixir and runs on top of the Erlang virtual machine as an argument for how incredible Elixir is, is naive at best, as Elixir is just a layer on top of many Erlang libraries and also the Erlang virtual machine. Yes, syntax can matter, but you can discuss that later when you discuss maintainability and other software design and maintenance issues. You cannot discuss syntax and then argue that your program sustains large amounts of traffic; you can, but it’s pointless.

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.

Thanks for your reply! All points you make are incredibly valid, but I still have some pushback:

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.

Why would you stop learning?

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.

Erlang was invented 30 years ago to solve problems that were not easily solvable by the back then prevalent programming languages. The claim that Erlang hasn’t brought anything new to the table couldn’t be further from the truth. Designing concurrent, fault-tolerant programs was not a problem solved in a satisfying way by the programming languages and technologies that were mainstream back then, which is exactly why Ericsson pursued the path of inventing their own programming language. I suggest everyone to read Joe Armstrong’s paper “Making reliable distributed systems in the presence of software errors”. It’s easy to read and mind expanding even if you do not intend to use Erlang. It can also save one from public embarrassment when one claims ridiculous things as parent and many other remarks in the other comments.

I acknowledged the areas where Erlang did bring advancements such as fault tolerance.

I read that paper, more than once, and his thesis, when I was doing my own PhD on parallelism, so I know the area and related work fairly well.

I don't think I'm embarrassing myself when I say that it's silly to claim that an arbitrary Erlang program should achieve linear scalability. But we don't need to debate with vague claims to originality - as I say Amdahl has done the maths and shows that it is only possible for a program that is embarrassingly parallel.

I think OP specifically talked about this assertion, "Your Erlang program should just run N times faster on an N core processor." This assertion is about parallelism, not concurrency.

I don't know what to say apart from that I disagree with how your describing my argument back to me.

Funny how often that's the only reasonable response. Nitpick: s/your/you're/. I do my part to stop language drift.

Erlang is a great programming language after one takes the time to understand the principles underlying it and its design. Everything fits very nicely into place. There are definitely things that could be done better, but then that’s the case with most programming languages and technologies after they have accumulated some dust. Elixir on the other hand, in my personal opinion, is a false prophet simply because it looks like something which it isn’t. It looks like Ruby and gives the programmer the feeling that he’s right at home, except it is in fact a very different beast with very different semantics, Erlang semantics, as opposed to Ruby. Therefore, if you want to program on the BEAM (the Erlang virtual machine) you better make sure you actually understand the system, its design, principles and also some of the semantics of Erlang itself, point at which you might as well just learn Erlang. I’m not saying that you cannot learn those things coming from Elixir, I’m just saying that if you want to build systems of reasonable complexity (like the ones that Erlang is known for) on top of the Erlang virtual machine, as opposed to CRUD web applications, then you must understand a lot more than just Elixir or Phoenix.

This is a big part of the reason why I appreciate having learned at least the basics of Erlang before moving on to Elixir, having come from Ruby. It helped establish an appreciation in my brain for declarative programming - something which is possible to do in Ruby, but nowhere close to the extent possible in Erlang or Elixir (or any other language with a similar approach to "pattern matching" as a first-class programming paradigm).

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.

Elixir is prettier than Erlang but it really mess up on certain things.

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)

end

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.

I honestly don't understand how this messes anything up... the elixir syntax produces something semantically equivalent with a lot less garbage. Opinions may differ I guess, but I find your Elixir example much easier to read than your Erlang example (I program in Elixir, so that's not much of a datapoint).

Most of the garbage is because those aren't the closest equivalents.

This is the closest Erlang equivalent:

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

It's not only that. I think the bigger issue is that because of it's Ruby-like syntax it encourages newcomers to think in Ruby rather than in Erlang. Rather than emphasising what's the core of Erlang it attracts people with it's syntax, which is the least important aspect of a language.

I think you make the Erlang definition look unnecessarily awful.

fac(0) -> 1;

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

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

It's an example from http://learnyousomeerlang.com

What you said is equivalent to a Python programmer saying that adding semantical value to the “end” keyword in Ruby is unnecessarily awful because you can achieve the same by giving meaning to the indentation level. It’s an entirely subjective matter.

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.

How does that matter? Anyone who uses this defines them in groups one after another. You aren't looking at the punctuation at the end of the line, you're looking at the following line to see if it's the same function name.

It matter because you're assuming they will group it. IIRC Erlang forces you to group it.

It's an incredibly safe assumption to make, though. This isn't enough of a problem in practice to amount to a negative for elixir or a pro for erlang.

I strongly agree. I've found it tremendously convenient to have an "alien" syntax (Erlang) to help me think Erlang-y.

(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.)