Elixir v0.13.0 released, hex.pm and ElixirConf announced(elixir-lang.org) |
Elixir v0.13.0 released, hex.pm and ElixirConf announced(elixir-lang.org) |
elixir : erlang vm (BEAM) :: clojure : jvm
Elixir's syntax is heavily influenced by Ruby but its semantics and structure is very reminiscent of Clojure. Like Clojure you are constantly reminded you live on JVM, with Elixir you are constantly reminded that Erlang is under the covers and thats OKAY.
Its really great stuff and the creator José Valim has really put thought, love and care into every part of the project. I highly suggest you take a look, you might be surprised at what you find.
It has immutable data but not immutable bindings. Erlang has both as immutable. What that means is, you can do x = value1 then x = value2. In Erlang, like in mathematical notation, once you said X=value1 it is value1, it doesn't make sense to say X=value2 (it throws an exception). In either case you can't modify value1 in place for example by saying x[3]=4 or X[3]=4 ( <- I am making up syntax to illustrate here).
Some like it one way some like it another.
Elixir has better meta-programming, which is nice.
In general, Erlang syntax is not the steepest learning curve. The steepest learning curve is to learn to use actors for concurrency and use functional programming for sequential parts. Elixir presents a more familiar syntax but the other learning curve parts are still there.
All of this while basically living in erlang. You can call erlang functions with a slightly different syntax, :erlang_module.function_name, and you can natively use erlang packages and files with mix(it checks for rebar/makefiles and makes educated guesses on how to build them, or you can configure it).
If you think its a benefit of Erlang its probably also a benefit to Elixir.
EDIT: I also forgot you get things like the threading macro(|> from clojure et al), built in testing framework, and a VERY active and helpful community on irc #elixir-lang and the mailing list.
Easy to configure and the deploys are pretty fast.
Disclaimer: I wrote it
For me it's not so much about bringing a nicer syntax to Erlang (Erlang's syntax is very nice once you get used to it, except for single assignment IMO. I'd prefer it if Elixir had taken Erlang's syntax and added support for rebinding variables and macros) but about tooling (mix, the build tool absolutely rocks) and libraries (e.g. take a look at http://github.com/elixir-lang/ecto).
Another way is to jump on irc freenode #elixir-lang and ask :).
Another way is to use it, report bugs, poor error messages or unclear documentation, and maybe fix it.
I did the later and the Elixir developers were super helpful and responsive.
also, jose valim must have clones of himself.
The elixir-lang getting started guide covers a ton as well.
I'd also highly suggest working through http://learnyousomeerlang.com/ as almost all of the concepts apply to elixir.
If you are having trouble hop onto irc freenode #elixir-lang and ask for help! Always someone willing to offer guidance, including the creators and some of the Erlang contributors!
The plan is to have v1 happen early this year and after that we'll start seeing more products being built with Elixir.
But really any project using Erlang can and probably will add some Elixir to its code base at some point. The languages complete interop between each other by way of sharing BEAM byte code.
I've been involved in the Rust community, a considerably larger, more active and more mature community, and I would consider a RustConf still a little premature.
Is there really enough interest in it? How many people are expected to attend? How many are needed to attend to break even in some manner?
Note Julia, Rust and Elixir are quite close to each other (which is nice considering they are about the same age). So, based on this data, I wouldn't classify Rust's community as considerably larger than Elixir's. Although Mozilla definitely helps Rust get some exposure!
Also I believe Elixir is more stable than Rust since Elixir runs on top of an existing Virtual Machine which helps us bootstrap the ecosystem and also skip a lot of "infrastructure work". We have also been avoiding breaking changes and doing deprecation cycles for almost a year now (sometimes it is unavoidable though) and Elixir has already 3 books in development (by O'Reilly, Manning and Pragmatic Programmers) with Elixir v1.0 planned for this summer.
Just to be clear, I am not knocking on Rust, just assessing the development stage of both languages (and please correct me if I got something wrong).
I am not sure about the conference details though, as I am just helping promote it, but wasn't there something like 20 or 30 people at the first RubyConf in US? We all need to start somewhere. :)
Rust, by the way, goes back further than 2012; it became public in 2010.
IRC:
- irc://irc.mozilla.org/#rust: 480 people
- irc://chat.freenode.net/#elixir-lang: 158 people
On GitHub:
- mozilla/rust: 414 watchers, 4,776 stargazers, 993 forks.
- elixir-lang/elixir: 217 watchers, 2,317 stargazers, 323 forks.
Reddit:
- /r/rust: 3,754 rustaceans, ~30 users here now, 172 posts in the last month
- /r/elixir: 448 developers, ~6 users here now, 14 posts in the last month
Mailing lists:
- rust-dev (it hasn't been split yet like elixir's are and is mostly development stuff; /r/rust is used more for other talk): 50 threads this month
- elixir-lang-talk: 45 threads this month
- elixir-lang-core: 23 threads this month
Stack Overflow
- [rust]: 294 questions
- [elixir]: 119 questions
Google Trends: https://www.google.com/trends/explore#q=rust%20programming,e... shows "rust programming" at around 3× "elixir programming"
I agree that elixir is a little closer to being a mature language (for Rust, 1.0 is not expected for some months yet, though probably still this year), and the elixir community does appear to be more active and mature than I had thought, but overall it still looks to me as though Rust has at the very least the larger community (I'll drop the active claim out of laziness and the mature claim for insufficient evidence) by a considerable way.
I thought Rust was from 2012 based on Wikipedia. It seems they choose 2012 due to the first alpha release. Elixir is theoretically from 2011 but you couldn't really use it for anything... the first actual release was in May 2012. Anyway, it doesn't matter much, just curiosities!
That's what many people see as the reason for homoiconicity after all. I put it in quotes, but maybe I should have said something about how languages can support sophisticated Lisp-like meta-programming without being a Lisp at all.
Nonetheless, as I'm still learning (aren't we all?), I would love to hear what a truly homoiconic language has above something like Elixir with its quote, unquote and unquote_splicing. By truly homoiconic I mean that AST is equivalent to the written form.
EDIT: I now realise you're not only rvirding, but that you wrote Lisp Flavoured Erlang https://github.com/rvirding/lfe so therefore (I hope) are in an even better position to educate!
In Lisp you are free to create completely new syntactic forms. Whether this is a feature of the homoiconicity of Lisp or of Lisp itself is another question as the Lisp syntax is very simple and everything basically has the same structure anyway. Some people say Lisp has no syntax.
Trying to build the AST that directly in elixir is quite difficult as the AST is not trivial even if it relatively simple and regular. Quote and unquote in macros do a lot of the work for you. At one level you could do something similar for Erlang but no one has actually gone all the way with it. Erlang uses parse transforms for that. They are more powerful but much more complex to use.
I would just like to add that in Elixir meta-programming does not always have to deal with macros.
For example, this program
somelist = ... # any kind of data,
# could be loaded from file
defmodule M do
for {name, value} <- somelist do
def lookup(unquote(name)), do: unquote(value)
end
end
While it is true that Erlang's parse transforms are more powerful by default, nothing would stop a willing heart from implementing token-level macros for Elixir. It would be a separate program that would parse source code before passing it on to the Elixir compiler.
But given the straightforwardness of code generation in Elixir (as exemplified by the code above), coming up with such a program might prove to be even easier for the user than dealing with parse transforms in Erlang. This is a speculation on my part, so it'd be curious to see if anyone goes in this direction in the future.
My opinion is that functions that take quoted code do actually do the 99% job of macros pretty well. I also think creating completely new syntactic forms is fantastic for a solo project; but not so great when working in a team. So I'm left thinking what difference does it actually make. My general feeling is that I tend to write macros in Clojure just to deal with someone else's macros; i.e. macros 'layer' whereas functions compose.*
Incidentally, I've been curious about but never looked at Erlang's parse transforms because they have - in my mind at least - a big 'here be dragons' sign above them. Enough articles have warned me off to make me nervous. Would love to know more though.
* No idea if that makes sense to people. Hope so.
We're not talking about MtGox here, which incidentally, was written in ::cue disdaining programmer voice:: PHP ::end cue::
I can implement any data structure, and if I define reduce for that data structure I get the entire Enum module for free, all tail call optimized.
It means I can mix and match data structures. I can do crazy things like zip a binary search tree and a lazy data stream together and then call take(5) to get the first 5 elements. And all that is required is reduce to be defined for all data structures. Protocols are a big deal.
The presence of protocols in Elixir enable many really cool features and designs that you wouldn't be able to do easily in Erlang.
Especially when a good chunk of developers come to expect to have basics like strings and library/syntax to support them natively.
Erlang isn't horrible, and when you learn Elixir you WILL come to learn Erlang and its documentation.
So X = [1,2,3]. in gives you variable binding X and variable value [1,2,3]. Variable value [1,2,3] is immutable in both Elixir and Erlang. You cannot do x[0]=5 in either one and expect the value [1,2,3] to be modified in place. Binding X is immutable in Erlang but not in Elixir. In Erlang you'd do X1=[5,2,3]. and in Elixir you could do x=[5,2,3].
You can argue what is better. I think both approaches are good, there is not one clearly superior in my opinion. Sometimes I take your side and prefer Erlang, because I like having explicit and immutable variable bindings that don't change behind my back. If I make X=[1,2,3], it is going to be [1,2,3] from now until forever.
As far as Actor and distribution stuff all that goodness is still in Elixir. They complement each other more than compete. Both take advantage of the awesome VM (BEAM) -- which I think is a marvel of engineering -- concurrent garbage collection, lightweight processes, scheduling balancing, async IO background threads, binary references, distribution and so on.
a = [1,2,3,4]
x = a
x = [1,2,3,4,5]
a == [1,2,3,4] => true
x == [1,2,3,4,5] => true
This is empirically NOT the same as ruby or even mutability.
This is a HUGE misunderstanding of Elixir. Once something is created you cannot modify it, PERIOD, you can rebind variables within the same scope. You cannot change the values.
Same thing is possible in clojure, and nobody questions that its immutable.
EDIT: And to be extra clear this is only within the same function. Not possible across functions, modules or processes.
[1]: http://queue.acm.org/detail.cfm?id=2068896 [2]: http://static.rust-lang.org/doc/0.10/guide-macros.html
An industry tends to congeal around a single technology for implementation (for example, Python in bioinformatics), so if bitcoin exchanges will start using Elixir, that is interesting
In Elixir macros are imported into local scope only when the user explicitly asks for it. Most libraries provide a `__using___` macro that can modify current scope.
For instance, `use ExUnit.Case` allows you to write tests like this
test "my test case" do
assert funcall() == "value"
end
require ExUnit.Case
ExUnit.Case.test "my test case" do
ExUnit.Assertions.assert funcall() == "value"
end
The consensus in the community right now is to not get carried away with macros and DSLs. Even if your library provides a DSL, it should be based on a functional API that is mostly usable without macros.
And lastly, remember that `use`, `require`, and `import` modify only the current lexical scope. I wrote this macro[1] that replaces the built-in `|>` operator with a version that prints its output to the console. You can `use PipeInspect` inside one function and only that function's body will get the overriden implementation of `|>`.
Cheers.
Yup. But what people say and what people do is often not the same thing :).