5 ms·

Dave Thomas has described Elixir as follows: "Elixir took the Erlang virtual machine, BEAM, and put a sensible face on it. It gives you all the power of Erlang

Dave Thomas has described Elixir as follows: "Elixir took the Erlang virtual machine, BEAM, and put a sensible face on it. It gives you all the power of Erlang plus a powerful macro system."[1] [1] https://startlearningelixir.com/elixir-for-rubyists https://startlearningelixir.com/elixir-for-rubyists

jbernardo95 10y ago
In other words, Elixir is the rocket that will make Erlang go big.
- rvirding 10y ago
  Well, it's a skin on the rocket that will make it big. While they generally say that Elixir runs on top of the Erlang VM there happens to be a big fat Erlang/OTP layer in-between which Elixir and its libraries make full use of. This is just smart of course but not mentioning doesn't paint the whole picture.
  - yellowapple 10y ago
    I'd say Elixir is the skin, like you say: without it, all your rocket pieces are out in the open and not particularly aerodynamic, and they'll start breaking off and you won't be going to space today. There are other skins, though, like LFE and Erlang itself. 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.
    - mnd 10y ago
      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.
      - yellowapple 10y ago
        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.
  - mr_luc 10y ago
    Wow, rvirding! Thank you for everything. Distributed software is actually a pleasure to write thanks in large part to your the many years of work. 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).
- hogrammer 10y ago
  Elixir is just for stupid people who need crutches.
mnd 10y ago
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.
- yellowapple 10y ago
  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.
- macintux 10y ago
  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.)
- digitalzombie 10y ago
  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.
tempz 10y ago
Not really. 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.
- kevinjcliao 10y ago
  https://blog.discordapp.com/how-discord-handles-push-request-bursts-of-over-a-million-per-minute-with-elixirs-genstage-8f899f0221b4#.5y7u46ajx https://blog.discordapp.com/how-discord-handles-push-request... 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'.
  - mnd 10y ago
    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.
    - kevinjcliao 10y ago
      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!
plainOldText 10y ago
There's also a very nice video explaining certain aspects of Elixir by Dave Thomas: https://youtu.be/5hDVftaPQwY https://youtu.be/5hDVftaPQwY
- mnd 10y ago
  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 https://youtu.be/xrIjfIjssLE
zengid 10y ago
It says Elixir uses the Actor model, but doesn't Erlang use Communicating Sequential Processes (CSP)?
zengid 10y ago
Alan Kay once said (at an Erlang conference): "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 https://youtu.be/fhOHn9TClXY?t=30m39s [2] https://youtu.be/fhOHn9TClXY?t=36m49s https://youtu.be/fhOHn9TClXY?t=36m49s

jbernardo95 10y ago

In other words, Elixir is the rocket that will make Erlang go big.

rvirding 10y ago
Well, it's a skin on the rocket that will make it big. While they generally say that Elixir runs on top of the Erlang VM there happens to be a big fat Erlang/OTP layer in-between which Elixir and its libraries make full use of. This is just smart of course but not mentioning doesn't paint the whole picture.
- yellowapple 10y ago
  I'd say Elixir is the skin, like you say: without it, all your rocket pieces are out in the open and not particularly aerodynamic, and they'll start breaking off and you won't be going to space today. There are other skins, though, like LFE and Erlang itself. 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.
  - mnd 10y ago
    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.
    - yellowapple 10y ago
      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.
- mr_luc 10y ago
  Wow, rvirding! Thank you for everything. Distributed software is actually a pleasure to write thanks in large part to your the many years of work. 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).
hogrammer 10y ago
Elixir is just for stupid people who need crutches.

mnd 10y ago

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.

yellowapple 10y ago
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.
macintux 10y ago
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.)
digitalzombie 10y ago
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.

tempz 10y ago

Not really. 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.

kevinjcliao 10y ago
https://blog.discordapp.com/how-discord-handles-push-request-bursts-of-over-a-million-per-minute-with-elixirs-genstage-8f899f0221b4#.5y7u46ajx https://blog.discordapp.com/how-discord-handles-push-request... 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'.
- mnd 10y ago
  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.
  - kevinjcliao 10y ago
    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!

plainOldText 10y ago

There's also a very nice video explaining certain aspects of Elixir by Dave Thomas: https://youtu.be/5hDVftaPQwY https://youtu.be/5hDVftaPQwY

mnd 10y ago
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 https://youtu.be/xrIjfIjssLE

zengid 10y ago

It says Elixir uses the Actor model, but doesn't Erlang use Communicating Sequential Processes (CSP)?

zengid 10y ago

Alan Kay once said (at an Erlang conference): "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 https://youtu.be/fhOHn9TClXY?t=30m39s [2] https://youtu.be/fhOHn9TClXY?t=36m49s https://youtu.be/fhOHn9TClXY?t=36m49s