4 ms·

Is elixir just a different syntax for erlang, or are the semantic differences? Their website doesn't seem to make it very clear.

erikj54 12y ago
Elixir is to Erlang what Scala is to Java. They leverage the Erlang VM in the same way that Scala leverages the JVM.
- jeremyjh 12y ago
  Actually it is not a good comparison. scalac compiles directly to byte code that runs on the JVM. Scala has pretty different semantics from Java. Whereas Elixir is compiled to the Erlang AST - a pretty high-level data structure - and then the Erlang compiler is invoked on this structure to compile byte code for BEAM. So whereas Scala can do things Java can't do (such as closures on Java 6), there really is nothing Elixir can do that Erlang can't. The fact that Elixir has the same semantics is really a good thing, because it makes it much easier to learn both languages at the same time and that is still pretty much essential in my opinion, if you want to become productive in Elixir.
angersock 12y ago
Elixir makes a lot of the syntax of Erlang (derived from Prolog) simpler and more familiar to people working from, say, a Ruby background. It adds better support for UTF8, better metaprogramming tools for declaring custom constructs, a standard library for things like collections and streams, proper default setup for some use of OTP patterns, and various other things. It adds a few sane default conventions for things like documentation, testing, and private/public visibility in modules. It in turn transpiles to Erlang, so has all the same performance characteristics.
- disbelief 12y ago
  Is it therefore possible to use Erlang libraries in an Elixir application, or to "drop to Erlang" in places where it could be advantageous?
  - gmcabrita 12y ago
    Erlang and Elixir can call each other with no overhead.
  - angersock 12y ago
    Yep! It's baller as hell. :)
pmontra 12y ago
They are pretty much the same. This is what Erlang's creator wrote about Elixir 1.5 years ago http://joearms.github.io/2013/05/31/a-week-with-elixir.html http://joearms.github.io/2013/05/31/a-week-with-elixir.html tl;dr there are good innovations and bad things, not a surprise :-)
losvedir 12y ago
I don't have any experience with it, but your question reminded of this article[0] that came up on HN a while ago arguing it's more than just syntax differences. Basically that it's more a Clojure/Scala than a Coffeescript. [0] http://devintorr.es/blog/2013/06/11/elixir-its-not-about-syntax/ http://devintorr.es/blog/2013/06/11/elixir-its-not-about-syn...
HashNuke 12y ago
Being able to use all of erlang's inbuilt modules and functions are an advantage. But there's way more to Elixir that just syntax. 1.) Elixir ships with a build tool called Mix. Falls back to use rebar for erlang projects. Mix is awesome and IMHO way more stable that rebar (Had problems with erlang libs shipping diff versions of rebar binaries in the git repo itself). 2.) There's a really good package manager - Hex.pm (developed and maintained by Elixir's co-author Eric) 3.) OTP compliant config. 4.) Pipes ~! This for me has been a very useful feature to decongest my code. I'm not sure what project had pipes first (should we credit F# or Unix shell itself?). Having that feature in Elixir is a boon for me. Finally about Phoenix: * More mature that most people think. It has a few features that even rails doesn't have (or even cannot handle in real world scenarios). There's support for "transports", which allows people to use polling or websockets and such if your apps need it. * Phoenix not having an ORM doesn't make a diff. Elixir's core-team develops and maintains Ecto, which is easy to drop it and start using. Ecto still has a long way to go, but for most apps, it is sufficient. * Authentication? Very simple to write a plug for that and share it across all Elixir frameworks. AFAIK someone wrote plug for OAuth.
- imanaccount247 12y ago
  >I'm not sure what project had pipes first (should we credit F# or Unix shell itself?) You'd have to go with unix out of those options, F#'s pipe operator is just flipped function application, and is primarily to make up for the poor type inference F# has. Every functional language has or can easily have a function application operator.

erikj54 12y ago

Elixir is to Erlang what Scala is to Java. They leverage the Erlang VM in the same way that Scala leverages the JVM.

jeremyjh 12y ago
Actually it is not a good comparison. scalac compiles directly to byte code that runs on the JVM. Scala has pretty different semantics from Java. Whereas Elixir is compiled to the Erlang AST - a pretty high-level data structure - and then the Erlang compiler is invoked on this structure to compile byte code for BEAM. So whereas Scala can do things Java can't do (such as closures on Java 6), there really is nothing Elixir can do that Erlang can't. The fact that Elixir has the same semantics is really a good thing, because it makes it much easier to learn both languages at the same time and that is still pretty much essential in my opinion, if you want to become productive in Elixir.

angersock 12y ago

Elixir makes a lot of the syntax of Erlang (derived from Prolog) simpler and more familiar to people working from, say, a Ruby background. It adds better support for UTF8, better metaprogramming tools for declaring custom constructs, a standard library for things like collections and streams, proper default setup for some use of OTP patterns, and various other things. It adds a few sane default conventions for things like documentation, testing, and private/public visibility in modules. It in turn transpiles to Erlang, so has all the same performance characteristics.

disbelief 12y ago
Is it therefore possible to use Erlang libraries in an Elixir application, or to "drop to Erlang" in places where it could be advantageous?
- gmcabrita 12y ago
  Erlang and Elixir can call each other with no overhead.
- angersock 12y ago
  Yep! It's baller as hell. :)

pmontra 12y ago

They are pretty much the same. This is what Erlang's creator wrote about Elixir 1.5 years ago http://joearms.github.io/2013/05/31/a-week-with-elixir.html http://joearms.github.io/2013/05/31/a-week-with-elixir.html tl;dr there are good innovations and bad things, not a surprise :-)

losvedir 12y ago

I don't have any experience with it, but your question reminded of this article[0] that came up on HN a while ago arguing it's more than just syntax differences. Basically that it's more a Clojure/Scala than a Coffeescript. [0] http://devintorr.es/blog/2013/06/11/elixir-its-not-about-syntax/ http://devintorr.es/blog/2013/06/11/elixir-its-not-about-syn...

HashNuke 12y ago

Being able to use all of erlang's inbuilt modules and functions are an advantage. But there's way more to Elixir that just syntax. 1.) Elixir ships with a build tool called Mix. Falls back to use rebar for erlang projects. Mix is awesome and IMHO way more stable that rebar (Had problems with erlang libs shipping diff versions of rebar binaries in the git repo itself). 2.) There's a really good package manager - Hex.pm (developed and maintained by Elixir's co-author Eric) 3.) OTP compliant config. 4.) Pipes ~! This for me has been a very useful feature to decongest my code. I'm not sure what project had pipes first (should we credit F# or Unix shell itself?). Having that feature in Elixir is a boon for me. Finally about Phoenix: * More mature that most people think. It has a few features that even rails doesn't have (or even cannot handle in real world scenarios). There's support for "transports", which allows people to use polling or websockets and such if your apps need it. * Phoenix not having an ORM doesn't make a diff. Elixir's core-team develops and maintains Ecto, which is easy to drop it and start using. Ecto still has a long way to go, but for most apps, it is sufficient. * Authentication? Very simple to write a plug for that and share it across all Elixir frameworks. AFAIK someone wrote plug for OAuth.

imanaccount247 12y ago
>I'm not sure what project had pipes first (should we credit F# or Unix shell itself?) You'd have to go with unix out of those options, F#'s pipe operator is just flipped function application, and is primarily to make up for the poor type inference F# has. Every functional language has or can easily have a function application operator.