Having rebinding of the vars and dictionary literals are really nice. The syntax feels a bit awkward in general. Commas have to be in non-obvious places, and the "do" keyword is essentially hard-coded. But these aren't huge problems. The homoiconicity looks quite interesting.
The bigger problem is that it still has 90% of Erlang's semantics, and that turns out to be just as different in Ruby-like syntax as it is in Prolog-like syntax. I should note that this isn't a problem for me, but if the aim is to make the language more familiar to others, the syntax change is not much help.
My team and I evaluated using Elixir for game scripting on an Erlang-based engine, but ended up passing because if we were going to teach the scripters Erlang semantics, we might as well just use Erlang. We also looked at LFE and came to largely the same conclusion.
But, I applaud the effort and I plan to keep an eye on the project. We need more of these kinds of developments on BEAM, and hopefully some of their good ideas will trickle into the Erlang language itself.
Hey metajack, glad you enjoyed some bits of the language and also thanks for the criticism.
Designing a language requires some trade-offs and the "do" is one of them. It is a keyword and its main goal is to reduce the number of parenthesis. You could write this in Elixir:
if true, do: (something; then_another_something)
But with do, you can give a many expressions straight away:
if true do
something
then_another_something
end
So, at first it may give the impression that the commas and do are aleatory, but after you get the hang of the syntax, it will hopefully make your code less noisy.
Finally, yes, the semantics in the end are Erlang semantics. My previous attempt at writing a language for the Erlang VM machine was fighting against Erlang semantics and that didn't end up well. :)
In the future though, you may choose to go with Elixir instead of Erlang because of its features. Macros and protocols are good features to make you more productive and your code more extensible. I am available for discussion at #elixir-lang on freenode.
That was a very simple example to explain which problem do/end is trying to solve. We also need to consider how your changes would fit with if/else, if/elsif/else and other macros like case/switch.
That said, please join #elixir-lang on freenode and I would love to talk with you about your suggestions. Maybe we can figure out some improvements?
Great project. I really hope Elixir takes off. I can try to convince my bosses that the transition from Ruby to Erlang isn't going to be syntactically hard :)
i do a lot of Erlang work - my consultancy - Inaka - has production apps in Erlang for Fortune 500 companies and startups - and I'm constantly looking for Erlang devs. Also, I have some ruby devs. I'm always trying to get the Ruby guys into Erlang but what I've found is that the concepts of Erlang are such that by the time you've learned the VM and processes, and atoms, and lists, and what a term is and what OTP is, you've got Erlang syntax down. So... I agree, I never actually have a need to teach Elixir. But, i REALLLY want it to work - it's a brilliant language and it's picking up where Reia left off - Reia is essentially dead now that (though not just because of the fact that) Tony works at Basho... so, I want to promote Elixir at the same time that I'm a huge potential user of it and don't (yet.).
My only thought about how Elixir could take off is if someone writes a killer web framework in Elixir and that starts meaning that the mixed apps we're always writing - Ruby on Rails web UI with an Erlang Web Services framework on the backend (that the iOS and Android apps are talking to) - could be just running inside the Erlang runtime. There would be no more need for that little piece of our deployment running Passenger - which is always the most fragile piece. That could do it.
i've used BERT and Ernie extensively and it's generally just easier to mix them using REST. But my point is we use Rails in some cases when we'd rather do everything in Erlang and (Mochiweb | Webmachine) because there's no good Erlang web framework, and I could see Elixir being the language foundation for that framework at some point.
Benchmark the performance of this on its own doesn't provide much insight. In any case, early benchmarks of the web server I am working on are available:
If this accomplishes what it seems to be attempting and makes erlang/OTP and the BEAM more accessible to the ruby, python and js communities while smoothing some of the language/platform's rough edges, I will be a very happy camper.
That's a good discussion. I could not find any concrete specification of what homoiconicity means. But there are other languages (like Erlang, Julia and others) which provides the same kind of "first-class AST" and are called homoiconic.
In any case, I believe we can agree what it is called doesn't matter much. What we can do with it, does. :)
The bigger problem is that it still has 90% of Erlang's semantics, and that turns out to be just as different in Ruby-like syntax as it is in Prolog-like syntax. I should note that this isn't a problem for me, but if the aim is to make the language more familiar to others, the syntax change is not much help.
My team and I evaluated using Elixir for game scripting on an Erlang-based engine, but ended up passing because if we were going to teach the scripters Erlang semantics, we might as well just use Erlang. We also looked at LFE and came to largely the same conclusion.
But, I applaud the effort and I plan to keep an eye on the project. We need more of these kinds of developments on BEAM, and hopefully some of their good ideas will trickle into the Erlang language itself.