[alco]

> We should avoid making Elixir a Ruby-on-Erlang when it has the potential to be so much more.

Elixir is fool-proof from turning it into a "Ruby on Erlang" simply because it embraces and improves on Erlang's programming model. Some libraries are ported over from Ruby. But there are also libraries ported from other languages and libraries that have been written for Elixir specifically.

Just a heads up: please don't make hasty generalisations based on a single project you've seen.

[skrebbel]

When I wrote "we should avoid making Elixir a Ruby-on-Erlang", i meant exactly that. I didn't mean the sugar-coated American oh my god how can I say this without being direct version of "we're making Elixir a Ruby-on-Erlang and this has to stop".

Sorry if you were offended, but I think you're reading more in my comment than there is.

Elixir is young enough that it can go many directions and it depends on the early libraries and frameworks what that will be, and we should be able to discuss that. I ended my comment with a question precisely because I don't actually know enough about Phoenix to judge it.

[alco]

I wasn't implying anything beyond the quoted phrase. My last remark was targeted at anyone reading the comment, I didn't mean to sound condescending towards you.

I don't share your belief that early libraries and frameworks have the potential to override Elixir's broad domain. In other words, even if there will be a widely popular library/framework for Elixir, it won't automatically negate its other strength or fitness for a wide range of uses.

During the recently held ElixirConf we've seen it used in a telecom company, also powering game servers, distributed robots, and hobby projects like an elevator controller and command-line applications. The community already has a diverse set of interests and many of us will be pushing the adoption in our respective areas of interest.

In any case, our best effort today would be to continue hacking and having fun with Elixir, and at the next year's conference we'll be able to see in which direction the trends go.

[mononcqc]

What do you mean by 'improves on Erlang's programming model'?

I've seen it improves on some tools and a fair deal of libraries, but I don't exactly see how it improves on the programming model itself?

[alco]

I realize now it sounds as if Erlang got something wrong and Elixir got it right instead. That's not what I wanted to say.

Elixir semantics is very close to Erlang's, but it also has things beyond what Erlang can offer as easily: macros, protocols, comprehensions with any kind of enumerable as a generator.

Of course, the core facilities provided by the runtime system are left unchanged: concurrency primitives, functional semantics, distribution, error handling (Elixir has slightly different conventions, but the idea of "letting it crash" remains). And in OTP land there are quite a few additions that simply make OTP more "elixirish" (like getting a lazy stream of events from GenEvent).