4 ms·

I don't know enough about the internals of the languages to speak on that, but here's what has influenced my decision on choosing Elixir: Community: smart peop

by tbrooks 11y ago

I don't know enough about the internals of the languages to speak on that, but here's what has influenced my decision on choosing Elixir: Community: smart people (who I respect) in the Ruby community are getting really excited about (and choosing) Elixir. People like José Valim, Dave Thomas, Bruce Tate, Chris McCord, etc. BEAM and OTP: The Erlang VM and OTP have been battle-tested at Ericsson. It's known for having 9 9's of reliability and scaled WhatsApp to millions of simultaneous connections. HEX: like Rubygems was for Ruby, Elixir/Erlang has a budding package management system via Hex. Hopefully this becomes the canonical source for libraries. Phoenix: Rails popularized Ruby and became the framework of choice for quickly and pragmatically developing CRUD apps. Phoenix has Rails-like conventions in building an Elixir app and has built in support for websockets. This framework is built for today's technology. Syntax: Coming from Ruby, the Elixir syntax is approachable and understandable. It's easy to jump into without having much prior knowledge. Kinda subjective, but those are reasons why I'm excited and choosing Elixir to build future projects upon.

nathan_long 11y ago
One thing that attracts me to Elixir is what it doesn't have to do. Go had to start from 0, Clojure had to build FP on top of Java. If they work at all, it's a success. By contrast, if Elixir just works, it's useless. Its functionality comes almost entirely from Erlang. Therefore its whole reason to exist is to make using that power more pleasant. That's why, for example, Jose Valim has said "if you see a bad error message in Elixir, which makes you confused and does not help you solve the problem, pls open a bug report." https://twitter.com/josevalim/status/621933537009246208 https://twitter.com/josevalim/status/621933537009246208
- davelnewton 11y ago
  Clojure built FP on the JVM, not Java. Elixir introduces language features onto BEAM. I guess I don't see the comparison making sense here. Elixir's functionality comes from BEAM and the language, not Erlang.
  - strmpnk 11y ago
    Elixir actually compiles to the Erlang AST and thus is leveraging Erlang much more than it might seem.
    - davelnewton 11y ago
      I see; I thought it compiled to BEAM code directly. I'd wonder then if there's anything representable in the Erlang AST that can't be represented by Erlang itself; it doesn't look like it so far.
      - klibertp 11y ago
        There's not - see docs for parse transforms. Erlang is homoiconic in the sense that it's parse tree is its own valid data-structure literal. This is also true for Elixir. The difference is the `quote` and `unquote` macros and a simpler parse tree format in Elixir, which makes meta-programming much easier than in Erlang from what I understand.
        nox_ 11y ago
        I have rarely read things that were that much wrong. Just because the code can be represented as a data structure, or just because the compiler is written in its own language, that doesn't make a language homoiconic.
        flackjap 11y ago
        I concur -> In computer programming, homoiconicity (from the Greek words homo meaning the same and icon meaning representation) is a property of some programming languages in which the program structure is similar to its syntax, and therefore the program's internal representation can be inferred by reading the text's layout. Wiki
        klibertp 11y ago
        Every language's syntax internal representation can be inferred by reading it's text layout. It's what parsers do and people can, too. How "similar" internal representation needs to be to its textual version to be homoiconic is subjective. In Erlang an expression: 2+3. yields this AST: {op,1,'+',{integer,1,2},{integer,1,3}} You can strip line and type annotations (you could also easily add them to the Prolog example below), which will get you: {'+', 2, 3} If you scroll down the Wiki page you cite, you'll see an example in Prolog, where this: X is 2*5 yields AST of this shape: is(_, *(2, 5)) The important similarity here is that all elements of ASTs are still first class objects in the language. You can manipulate them in their raw form with the same functions you'd use for manipulating any other data. In other words, once you have an AST, you don't need to evaluate it, it's enough to just read it. This is not true for Python. An expression: 2+3 yields: Expression(body=BinOp(left=Num(n=2), op=Add(), right=Num(n=3))) An AST here cannot be manipulated in its raw form here. To manipulate it - the representation itself - you'd have to parse it again or evaluate it to use special methods on AST objects. So this is the practical definition of homoiconicity I came up with. You are of course free to disagree. I'm stressing "practical" here, because what I'm interested in is how easy it is to manipulate the AST to write macros. Homoiconicity for the sake of homoiconicity is of no interest to me. PS. BTW, maybe I should base my argument on Lisp instead of Prolog. If you read the Wikipedia page carefully you'll see the part on Lisp says the same thing I do above.

by tbrooks 11y ago

nathan_long 11y ago

One thing that attracts me to Elixir is what it doesn't have to do. Go had to start from 0, Clojure had to build FP on top of Java. If they work at all, it's a success. By contrast, if Elixir just works, it's useless. Its functionality comes almost entirely from Erlang. Therefore its whole reason to exist is to make using that power more pleasant. That's why, for example, Jose Valim has said "if you see a bad error message in Elixir, which makes you confused and does not help you solve the problem, pls open a bug report." https://twitter.com/josevalim/status/621933537009246208 https://twitter.com/josevalim/status/621933537009246208

davelnewton 11y ago
Clojure built FP on the JVM, not Java. Elixir introduces language features onto BEAM. I guess I don't see the comparison making sense here. Elixir's functionality comes from BEAM and the language, not Erlang.
- strmpnk 11y ago
  Elixir actually compiles to the Erlang AST and thus is leveraging Erlang much more than it might seem.
  - davelnewton 11y ago
    I see; I thought it compiled to BEAM code directly. I'd wonder then if there's anything representable in the Erlang AST that can't be represented by Erlang itself; it doesn't look like it so far.
    - klibertp 11y ago
      There's not - see docs for parse transforms. Erlang is homoiconic in the sense that it's parse tree is its own valid data-structure literal. This is also true for Elixir. The difference is the `quote` and `unquote` macros and a simpler parse tree format in Elixir, which makes meta-programming much easier than in Erlang from what I understand.
      - nox_ 11y ago
        I have rarely read things that were that much wrong. Just because the code can be represented as a data structure, or just because the compiler is written in its own language, that doesn't make a language homoiconic.
        flackjap 11y ago
        I concur -> In computer programming, homoiconicity (from the Greek words homo meaning the same and icon meaning representation) is a property of some programming languages in which the program structure is similar to its syntax, and therefore the program's internal representation can be inferred by reading the text's layout. Wiki
        klibertp 11y ago
        Every language's syntax internal representation can be inferred by reading it's text layout. It's what parsers do and people can, too. How "similar" internal representation needs to be to its textual version to be homoiconic is subjective. In Erlang an expression: 2+3. yields this AST: {op,1,'+',{integer,1,2},{integer,1,3}} You can strip line and type annotations (you could also easily add them to the Prolog example below), which will get you: {'+', 2, 3} If you scroll down the Wiki page you cite, you'll see an example in Prolog, where this: X is 2*5 yields AST of this shape: is(_, *(2, 5)) The important similarity here is that all elements of ASTs are still first class objects in the language. You can manipulate them in their raw form with the same functions you'd use for manipulating any other data. In other words, once you have an AST, you don't need to evaluate it, it's enough to just read it. This is not true for Python. An expression: 2+3 yields: Expression(body=BinOp(left=Num(n=2), op=Add(), right=Num(n=3))) An AST here cannot be manipulated in its raw form here. To manipulate it - the representation itself - you'd have to parse it again or evaluate it to use special methods on AST objects. So this is the practical definition of homoiconicity I came up with. You are of course free to disagree. I'm stressing "practical" here, because what I'm interested in is how easy it is to manipulate the AST to write macros. Homoiconicity for the sake of homoiconicity is of no interest to me. PS. BTW, maybe I should base my argument on Lisp instead of Prolog. If you read the Wikipedia page carefully you'll see the part on Lisp says the same thing I do above.