Ah, this is great. Hopefully now there won't be updates that alter syntax and functionality with quite the same frequency! (check the 'Upgrading from...' posts)
I'm pretty excited about Elixir and Phoenix. Building on Erlang's OTP should mean scaling can be fairly transparent.
I have been working with Phoenix for about a year. Upgrading hasn't been bad. The most inconvenient thing was when Ecto changed some APIs to return tuples, and changing Ecto.Repo.update/2 to be a no-op with no changes. It really isn't that bad with a good test suite though. :)
Great work Chris, Valim and everyone else involved.
I like the screenshot of htop on the front page with all CPUs working along. And a shoutout to the Erlang's Observer tool as well, to inspect the running system and show process dependencies.
Does phoenix require javascript, or just this announcement page? I see a big block of text mixed with json... Not so good for noscript users and search engines that don't load JS.
We use readme.io to host our guides and blog. They use angular I believe, so maybe a hiccup on their end? Phoenix itself targets html/form, spa's, and api's alike.
JavaScript may well be practically required, but there are people/agents that don't have it, and dumping piles of json data on them is a poor fallback.
No, you can use phoenix without any javascript, it'll serve up regular html pages just fine. You only need the js if you plan on using sockets to connect to Phoenix's endpoints.
I've been getting into serious production-ready web development for some time now and Rails has been the tool that kicked things off for me. However Phoenix and Volt are alternatives that have been on my radar recently and really caught my interest. Glad to see it reaching this milestone. Congratulations!
I've been getting into serious production-ready web development for some time now and Rails has been the tool that kicked things off for me. However Phoenix and Volt are alternatives that have been on my radar recently and really caught my interest. Glad to see it reaching this milestone. Congratulations!
It's also worth noting that Ecto [1], the core-maintained Elixir ORM-like package, also hit v1 earlier this week and has backends for dealing with: PostgreSQL, MySQL, MSSQL, SQLite3 & MongoDB.
Ecto isn't an ORM since Elixir isn't OO. Terminology aside, Ecto identifies more as an Integrated Query Language in a similar vein as LINQ does in the .NET ecosystem.
As someone who has used lots of ORMs I find the switch to a libary like Ecto very refreshing. It has an intuitive and very composable querying API and friendly DSLs for defining schemas and validations. These are the baseline features of any database/modeling library and Ecto satisfies them nicely.
But by far my favorite feature that has come in handy is that Ecto's concept of Repos does not couple you to a specific database. Unlike traditional ORMs that couple your objects to a specific database (read: the my_cool_app database in MySQL or Postgres) it's easy to support different databases within the same type of RDBMS or different RDBMS entirely. Since all querying in Ecto goes through Repo modules all you need to do is just create more Repo modules and configure them accordingly.
For some people this feature might not sound useful but if you've ever worked on an Enterprise or older app with multiple data sources or want to switch from MySQL to Postgres, this is a killer feature. Doing this with Rails' ActiveRecord is ugly, buggy, a pain and will bring you to your knees during Rails upgrades any time there are major changes in ActiveRecord.
I've worked with multiple ORMs (Hibernate, Rails ActiveRecord, and Grails GORM), and I've always been able to easily switch betweens RDBMS's unless I specifically decided to step out of the ORM and use a DB-specific feature or query. I'm not sure what you mean here?
By switching I mean I want one query to go to this database and another query to go to a completely different database at the same time. Can you do this in other ORMs? Yes. Does it almost always involve a third party library that monkey patches your ORM's connection pool? Yes.
I've used Rails, but a long time ago. However, I really enjoyed Ecto; the migrations, the query interface etc. Still wrapping my head around changesets (I think it's quite simple, but when I began with Phoenix there were just so many new concepts).
Very exciting that they are branching out to support MongoDB as well. I'd love if they could support more untraditional Postgres operators for arrays and json (I guess there's always a tension between least common denominator and using the specialized features of each DB). You can get around it with partials, but it makes the code more messy.
Personally, I have enjoyed using it. I prefer to stay closer to the SQL than perhaps most would and writing queries in Ecto felt a lot like SQL but with added composability.
Unfortunately, I don't have experience with using the ORMs you listed in anger so I can't make a direct comparison. Anecdotally, I have found it much nicer to use than Django's.
My NDC Oslo talk gives a nice overview of the framework, Elixir, and its Erlang roots for those that want to evaluate the stack before jumping in https://vimeo.com/131633172
Phoenix and Elixir are really great tools. I spent the summer building a bunch of interactive components for an EdX MOOC (https://imgur.com/a/rAXVz), and got to try out a lot of Phoenix capabilities (channels/websocket support is great!), but also using underlying Elixir/Erlang libraries for task-queues, email sending and receiving, etc. Super stable, never able to get our server above a few percent of CPU :)
Do you have any blog posts on task-queues and email sending/receiving? I'm trying to learn Phoenix and Elixir by rewriting an app I have that does just this.
Sidekiq has been great as a background worker, but I'd like to try concurrency elsewhere.
Just wrote something on [sending errors by emails](http://reganmian.net/). The full code is here: https://github.com/houshuang/survey, including my job module https://github.com/houshuang/survey/blob/master/lib/job_work.... The code worked well for me, mostly because it registers errors and retries (I had problems with rate-limiting of Amazon SES), however it's not parallel right now. I will probably rewrite it to have a single module that gets tasks from the DB, and then dispatches it to workers, and I want to split it out into a separate library.
Note that this was my first Elixir library and I was very much learning as I went along. Lot's of code that I want to refactor and extract.
If you're curious about the framework as well, here's the source for an app I made for peer-to-peer file sharing in Phoenix: https://github.com/hayesgm/fuego. You can try it out here: https://fuego.link
Phoenix has really been exciting to use. It's a great way to get introduced into the OTP system from Erlang (plus all of Erlang's modules), it's incredibly fast, and the immutable data structures make it easy to reason about your concurrent code. I would strongly suggest giving it a try.
Awesome! Great work Chris and Jose and everyone else.
Getting my feet wet with a few side projects and am really loving Elixir and Phoenix. Performance is great and I don't miss too much compared to Rails. I still love Ruby and Rails, but will most likely default to Phoenix/Elixir for most future projects.
I primarily use Django REST Framework for APIs... has anyone moved from Django to Phoenix and can give a report on how the developer productivity compares currently? If it's not there yet I'm sure it will get there as the community grows but how is it now?
Phoenix is more like Flask in that regard and definitely doesn't come batteries included like Django (no auth, no admin, no cache backends etc) so it would be more work to build something as full-featured as DRF on top of it.
Having said that, I've found it easy to get along with retuning JSON and the actual speed of responses is incredible. Completely anecdotal and unscientific but one service I recently converted from DRF to Phoenix saw drops in avg response time of 350ms to about 15ms.
If you are doing REST apis and are interested in Elixir I'd recommend checking out Trot (https://github.com/hexedpackets/trot). If is a lightweight wrapper around Plug (Exilir's middleware framework) and Cowboy (Elixir's native http server).
As Jose was one of who contributed the most of RoR code and now is focusing on Elixir/Phoenix, will the RoR community move to Elixir/Phoenix? I think so, as Rails 5 doesn't seems to be that promising as one discussion here took place
When people choose to build on a more esoteric language such as Elixir (and to lesser extent Erlang) is it because what they want to do simply is not possible in Ruby/Python/Go/JavaScript/etc or just less efficient, elegant, productive, etc?
The latter. The virtues of Elixir is that it is a functional language with immutable data structures, and that it does not support object oriented programming (which I consider a feature).
That's because the core of OO (message passing to opaque things) is really all you can do if you have a PID. In other more-traditional object-oriented languages, they usually have defaults that let you do more than just send messages - such as mutate the internal state directly in ways that the object cannot detect.
Erlang/OTP is great fit for building applications that support a huge amount of concurrent users, but the problem is that IMO Erlang is nowhere near as pleasant to work with as Ruby, Python, etc. So if you're building something with zero users and choosing Erlang because of the ROFLscale potential it's premature optimisation. Elixir is the difference. I am just as productive in it as anything else and I enjoy it much more. So what we have is the massive power and potential of Erlang/OTP with a productive, pleasant API and great developer tools (Mix, Hex, etc).
my employer uses erlang because it's a huge leap forward operationally over ruby/python/go/java. the erlang/otp concept of a release is extremely straightforward and reliable and the beam (erlang/elixir vm) run time introspection and debugging tools are second to none. it's trivial to attach to any running application and get a REPL with full access to the environment. you can even update running code in place
how do people typically put security (authentication and authorization) around this? You wouldn't want just anyone to be able to connect to your running apps, of course. From what I saw in Elixir, there's some kind of cookie/session key that you can specify, but is that it or is there more?
> is it because what they want to do simply is not possible in Ruby/Python/Go/JavaScript/etc
There are several key distinctions about Elixir vs the other languages you mentioned. These are things that are basically not going to happen in Ruby, Python, Go, Javascript, or etc.:
1) You get the benefits of Erlang/OTP as others have mentioned in their replies.
2) You also get the amazing macro capabilities (runtime code execution and runtime code generation, a la LISP) that Elixir brings to the table. Many of the language features of Elixir are written in macros in Elixir. The source to both Elixir and Phoenix are quite elegant and educational to browse, and demonstrate this runtime code generation aspect very well. It's straightforward in Elixir to introspect code, represent that code as data structures, manipulate those data structures, then generate or execute that code, as you can in LISP.
3) Immuatable data and functional style leads to better code in lots of ways. This is what really makes the benefits of OTP possible (updating the code without restarting the servers, easily migrating state between servers, and so on). But it also makes certain kinds of situations easier to understand and fix, since all state in the system can be expressed as parameters to functions.
Everything is possible in a Turing complete language (assuming enough of base utility functions are provided by stdlib), so the question is not possible vs impossible, but how much of a help the tool is.
Erlang provides great abstractions for building fault-tolerant, scalable, distributed, soft real-time systems. That's not to say you can't do it with Erlang, but Erlang does give some simple, yet very powerful tools for making developer's life easier.
Without Erlang you have to work harder to get similar effects. Again, it's not impossible but there's more burden on developers because the runtime provides less guarantees. I elaborated a bit on the topic in the promo interview for my book (http://www.infoq.com/articles/elixir-in-action-erlang-review).
I did. I love Rails. Love it. Love Ruby. I've been writing code for over 25 years this year, and I've been doing Ruby for 10. And I hit a big brick wall with a very websocket-heavy app I'm building.
I switched to Elixir and Phoenix last year and got the core of my app working.
It's funny though - the core is easier. But many freebies from Rails aren't there yet. So I still don't have password recovery emails or confirmation emails on signup done yet :)
The Devise gem does that for free. I remember me coding it in my first Rails application so many years ago and I'm not keen to go back to it: it feels like wasted time. Phoenix didn't have it one year ago and it's sad to learn that it doesn't have it yet. Somebody will write it sooner or later because it's almost core functionality of a registration and authentication system.
Its actually pretty simple to implement on your own. I am not big of device. I feel it does too much magic. It should have been just a api layer and not touching views.
It's simple to write a password-based auth system. Then you must clear session appropriately.
Then you must create the login page.
Then the controller for authenticating. And then you need to ensure that the flow works with a test.
Then you need the email that actually activates the account, with the activation hash. So now you're setting up a mailer system, which Phoenix does not have by default.
Then people will want to recover passwords. So you need to write the logic for that. Oh, and the controllers and views. And routes.
And of course, you need to hash the password using some kind of encryption. Excrypt, comeonin, what have you. Choices choices choices.
You'll need a plug to act as the bouncer for your routes too, so nobody gets in where they shouldn't. So you'll have to write that.
You have to end-to-end test this, of course. And probably, if your business depends on it, get a couple other people to review the security of your system.
Simple. And takes a long time.
HTTP is pretty simple, but we use frameworks. SQL is pretty simple too, but we use Ecto now.
It's simple in its pieces, but I really don't wanna do all that work on every app. I'm lazy.
This is awesome! I've been working with Phoenix for a bit now, and aside from the fact hex/phoenix doesn't yet have all the libraries that rubygems/rails have, Phoenix has blown my expectations out of the water. For such a big and complex framework, the entire functional plug system (functional is love, functional is life) makes the whole thing easy to grok in a way utterly unimaginable in a traditional rails framework.
By the way, in case core team is reading, what's the motivation behind removing infer_model_view from the render functions?
I haven't done much either with Elixir or Ruby (I do more Python and Erlang). But one thing I noticed is Valim (and others on the team) created a really approachable langauge and framework. Their emphasis on new comers, documentation, friendliness of community is outstanding.
Also Elixir will bring more people to the BEAM VM and take advantage of it, as I think it is a gem of engineering.
It's great having new people, but hopefully we'll avoid the clusterfuck of gems and node modules that are the hallmark of the perpetually-immature web development community.
I know you're being downvoted but I 100% agree with you. I don't want 100,000 Hex packages. I want a few thousand packages that solve problems really well and people rally around and collaborate on them. NPM and RubyGems are casualties of people seeking open source fame and I hope we can avoid that in Elixir.
This is totally nonsense. Any among those 100000 could become the most used library in their specific field at some point in time, and the fact that you can choose to contribute to whichever you like more, or create your own is the beauty of OSS. If you fear this will weaken devs ability to focus their strength on just one common solution, and be inefficient, then you really don't know how OSS works. What you want to impose, is something that already happens spontaneously in OSS (one gem taking over the other, unless they provide very different features or to do things in a drastically different manner).
> NPM and RubyGems are casualties of people seeking
> open source fame and I hope we can avoid that in Elixir.
No, they're casualties of people actually using the platform, the platform's low publishing barrier, and the ecosystem's preference for focused libraries over monolithic bouncy castles.
Rallying around one library sounds cool until you see that the top three competing solutions in another ecosystem each have more contributors and activity. Then you realize you're not in the elite ecosystem, just the smaller one that has one library like my tiny Texas hometown.
After spending nearly 7 years in the Ruby and Rails ecosystem, I changed jobs and have been working in with Elixir and Phoenix for nearly 3 months. I have been very satisfied with the process. The community is amazing, the tooling is unbeatable, and the quality and availability of open source libraries is great, especially for such a young project. The future looks very bright for Elixir and Phoenix!
I like Elixir because of its ability to do distributed computing, fault tolerance/HA, binary pattern matching, speed, and more. You don't need Elixir, but it makes a lot of stuff much easier to do.
Agreed. One of the many things that makes Phoenix/Elixir great for us rails/ruby refugees is that it's built by other rails/ruby refugees. In many ways, we have all the good things that our old masters DHH trailblazed with rails, but at the same time, very little of the mess that also came with the trail-blazing.
That being said, I do miss active_support though; Elixir's utility libraries (fox, pipe, croma, etc.) doesn't yet have all the easy automagic that made rails so simple to develop on.
1) Referring to DHH and others as a "our old masters" instinctively bothered me.
2) While I appreciate that Elixir and Phoenix have Rails connections and can learn from it, I'd prefer it not become just a place for Rails refugees where it turns into a huge circle jerk about how Rails is terrible and Phoenix is great (which happens all too often in communities).
Other than that, I agree. But we should start something new.
The flip side is that everyone is trying to write Ruby packages and projects in Elixir rather than thinking out of the box as to what is best for this new programming paradigm.
Better for building out services. Parallel processing. The supervised process abstractions are incredibly powerful.
If you're building another Twitter I would still use Rails. You'll be much more productive.
On the other hand, if you need to run parallel tasks or have mission-critical (aka can't go down for anything) work to be done I think you'll find Elixir the perfect combination of Ruby's syntax and Erlang's power.
Just my $.02 - I'm having a blast with Elixir at the moment.
Nah, if you really are trying to build the next Twitter Rails is a poor choice for architectural and scaling reasons. No need to repeat Twitter's own mistakes.
On the other hand, if you are just building another web app, Rails is the better choice...
Phoenix shares many features with Ruby on Rails, e.g. a strong MVC model, an integrated ORM, a routing system, etc. What Phoenix on Elixir excels at is concurrency and distributed computing. For applications, this means you can have many active web sockets, for instance, where Rails applications tend to break down when you have too many active connections. Phoenix uses erlang processes for these tasks, which are lightweight and can number millions on a single machine.
As an example, Heroku uses cowboy (the erlang web server that Phoenix uses) for load-balancing incoming connections to all Heroku applications. The erlang VM (BEAM) is great for these types of highly concurrent, highly available, distributed tasks. The original use case for erlang was highly available phone switching for Ericsson.
This is very interesting as Phoenix could become the next Rails. I loved Rails and ruby, for the most part, but ruby MRI still lack 'Native Threading', and Jruby isn't viable if you are using external C extensions.
To overcome the lack, I've used Resque (or beanstalkd in PHP, which has the exact same problem) as a background job manager, but then I had to write my own layer and rely on the database to handle the 'job' result.
Which parts of the framework leverage the concurrency model, other than the routing/request handling part?
The best example is probably channels. The framework doesn't really have to provide you anything for you to be able to use concurrency. For a personal example, I was able to use RethinkDB changefeeds easily with channels: https://github.com/bbhoss/elixir_friends/blob/master/web/cha...
Another example is sending email. In Rails, you need to have something like Sidekiq (or now Activejob) to be able to background the job so it doesn't block the response to the client. In Phoenix, you can simply spawn a process to do the work and move on. Sure, you might want a system like exq to keep track of things a bit better, but ultimately the concurrency primitives provides by Erlang/Elixir allow you to do everything you need.
Another example: I work on a Rails app where the user submits a request to us, and we have to talk to an API to respond. We can't afford to leave the connection open with the user, so we make them poll for results.
My understanding is that the cheap processes of Elixir would mean we could just keep a connection open to that user if we wanted to. Similarly, no need for a background processing framework like ActiveJob; just use processes.
What webserver are you using? Running puma in threaded mode, even on MRI, should allow your external API calls to run in parallel - this might simplify things a bit :)
That's right. Because Elixir is 10x faster than Rails, we don't need to worry about caching so much. And because it supports cheap concurrency, we don't need to offload long running tasks to a background task. So the overall structure is simpler.
And this works across the whole architecture. One of our projects right now is a mobile medical application for medical where caregivers communicate in real time with a number of patients. We have the mobile app talking to the server using a REST API and real time messaging for chat. The caregivers can communicate with the server using a web application with integrated web chat or via an XMPP client. And we have the normal public web and admin CRUD. All via a single server process in a single language. This is what Elixir/Phoenix was made for, it enables a new generation of modern apps.
If this framework gets too popular they'll probably rename it to Firebird. Let's just hope there isn't already another open source software called Firebird.
I believe that's the joke! I usually never mind when projects have duplicate names, but c'mon, "Phoenix"?! Zero points for creativity there - I sure wish there were more things in history than rose from the ashes ;)
Does Elixir have any kind of signal processing capabilities ala numpy/scipy for the Python ecosystem? I'm doing some stuff right now using a django/nodejs hybrid system (glued together manually) and I'd love to be able to do everything in one language. But the DSP support (seemingly) isn't there in the javascript ecosystem yet.
I'd really love something built on erlang because of all the theoretical problems that just don't happen because of the way it's built.
Getting to 1.0 is really awesome. Although I have a lot of 'framework fatigue' at this point, what would be really helpful for me would be why this framework is better than the dozen other frameworks along any number of axes, say "time to develop", "spinning up new developers", "obsolecence protection", anything which would provide a compelling story why this instead of Angular or React or Bootstrap or Eve or anything else for that matter.
I don't have time for a longer response at the moment, but Angular/React are front-end frameworks, and Bootstrap is a css framework. In case you missed the 2nd sentence:
> Phoenix is set to take on the world whether you're building APIs, HTML5 applications, or network services for native devices.
My NDC Oslo talk (linked in this thread) would answer your questions if you have the time to watch it. I give a high-level overview of Phoenix, Elixir, and the Erlang virtual machine and the virtues of how it all fits together. I'll try to get back later with a broader overview.
Thanks Chris, my suggestion is that you link that talk on the announcement page too, my guess is that other people who are looking at Phoenix for the very first time since its now 1.0 will benefit from that information.
True, my thinking was one level up the stack, Phoenix is (according to Chris' talk) a framework for building applications. And it does this using Elixir running on Erlang. Is Elixir special?
Sure it is, but "framework for building apps using language X which is run by virtual machine Y" is the basic pattern for JavaScript, Clojure, Scala, Java, and others. There are a lot of them, they have varying levels of integration.
Can I build a discussion forum in Phoenix? Sure, it has all the tools. Can I build it using PHP or Ruby? Sure those have tools too. Can I create an integrated IDE with my langauge and my execution environment? Sure we can do that too like Light Table.
So is it just Visual Basic all over again? Thinking of it that way is probably not conducive to polite conversation :-) but in many ways it is. We have a scripted language (Elixir), a virtual machine (Erlang), a "window" system (HTML5), and a set of APIs we can call on.
That is great, doesn't solve a new problem but solves an existing problem in a new way. And I watched Chris' talk and read the documentation, and I still don't feel like I have a good feel for why its better than what came before.
There are lots of "new" problems with respect to changing conditions in our day to day lives. Here are a few
- Identity management across Internet and non-Internet properties
- Configuration, control, auditing, and monitoring of billions of Beacon level devices
- Zero knowledge proofs as a technique for anonymous and no repudiated purchases online
- "home" level cloud services for local and on the road implementation of always available services (mail, journaling, calendaring, Etc.)
- Reliable third party payment systems (somewhat of an old system but one that benefits from revisiting with current technology from time to time)
- Navigation and cartography tools for people in disconnected regions of the planet.
- Civil process augmentation with automation and authentication.
- Connectivity as a tax payer civic utility, without an editorial bias.
-Dynamic skills assessment for students in the presence of confounding factors (mostly remote access)
- Low friction capital markets for charitable giving (think Watsi but for everything, and with better controls than 'GoFundMe')
- Providing civic services for indigenous homeless populations.
I could go on, there are lots and lots of problems. But to be clear it isn't a criticism of Phoenix that they are not solving a new problem, the feedback was that there are lots of solutions to the general form of problem they are solving and, as feedback on this announcement, I was trying to learn from their materials how they were different (and presumptively better) than those other solutions. I'm still looking for that summary somewhere.
Slightly off-topic, but can someone familiar with both Elixir and Erlang explain what Elixir provides in comparison to Erlang.
I'm looking into using Erlang for a new project that requires extensive scaling and concurrency and am coming from a functional background so may be more comfortable with the traditional Erlang syntax. However it seems that perhaps more development and activity is happening on the Elixir side of things and it may be more productive in terms of tooling, libraries (such as Phoenix and Ecto), and support.
I have worked a bit with elixir and erlang lately, but i'm not means an expert. I have to say, the biggest advantage elixir has against erlang for me is the macro system. It seems to manage to combine a ruby-like syntax with lisp-like macros, and it works incredibly well. Because of this it is very easy to create DSLs.
I'm a long time Erlang programmer and still prefer Erlang. But anyone who asks about web programming I point to Phoenix. So if you are doing a web app, or have a web component, I'd suggest Elixir and Phoenix for that part :)
> can someone familiar with both Elixir and Erlang explain what Elixir provides in comparison to Erlang.
The syntax is nicer, but that's just a bonus. The real game-changer to me about Elixir vs Erlang is its macro system. This gives you runtime code execution and runtime code generation, similar to what makes LISP to powerful.
There's a large amount of boilerplate involved in creating an OTP server, as you know if you've done any Erlang. Elixir's macro capabilities completely eliminate all the boilerplate.
The source to both Elixir and Phoenix are quite elegant and educational to browse, and demonstrate this runtime code generation aspect very well. It's straightforward in Elixir to introspect code, represent that code as data structures, manipulate those data structures, then generate or execute that code, as you can in LISP.
Elixir also gives a number of excellent tools that streamline the support process over vanilla Erlang. For example, Elixir's runtime tooling automatically manages dependencies for you (similar to node's npm), and automatically maintains the application string that you need to provide for all OTP applications. It also has improved capabilities for testing, which are also made possible by the amazing macro generation capabilities.
> I'm looking into using Erlang for a new project that requires extensive scaling and concurrency and am coming from a functional background so may be more comfortable with the traditional Erlang syntax
Elixir's syntax is still just as functional. They support a regular if statement, unlike Erlang, but generally it's just as functional as Erlang. Elixir eliminates a number of needless chores from Erlang, such as having to end some lines of code with a comma, and others with a period, and then shuffling punctuation around whenever you add or remove lines of code. That's a task I used to do literally a hundred times a day in Erlang that I don't have to do at all any more.
You can do reasonable metaprogramming in Erlang with the syntax_tools and stdlib interfaces. Most famously was bringing back parameterized modules via a parser transformation for tools like BossDB to support ActiveRecord-like ORM patterns.
I've looked at OTP the Elixir way and I do not see any real boilerplate reduction. The application-project dichotomy and the opinionated integration with a tool like Mix is also policy over mechanism.
rebar3 does fine dependency management given its constraints of having to unify packages coming from disparate sources.
The syntax is not nicer. It is a jarring conceptual mismatch to put Smalltalk-ish Ruby syntax over a language that eschews excessive monkey patching and dynamism like Erlang.
> You can do reasonable metaprogramming in Erlang with the syntax_tools and stdlib interfaces.
You can also do concurrency in Ruby. It is not the same as doing concurrency in Erlang though. The same way doing metaprogramming with syntax tools, parse transforms and what not is nowhere close to a macro system.
> I've looked at OTP the Elixir way and I do not see any real boilerplate reduction.
So please look again? Take a look at Elixir's agents or tasks and explain how it doesn't lead to more readable and cleaner code than the GenServer equivalent in Erlang for the cases they fit. You could maybe point other criticism but saying "no real boilerplate reduction" just shows you didn't really try or care to give it a try.
> It is a jarring conceptual mismatch to put Smalltalk-ish Ruby syntax over a language that eschews excessive monkey patching and dynamism like Erlang.
This sentence is specially ironic given that Erlang inherits from Prolog, which is quite different semantically from Erlang, instead of using the more tradicional ML families. Also Erlang is pretty much a very dynamic language.
I am a Haskell developer, I hate Ruby syntax and I programmed Erlang for a year. I would still choose Elixir over Erlang any day mostly because of the tooling, typeclass like polymorphism and the new abstractions (Task and Agent).
The same way doing metaprogramming with syntax tools, parse transforms and what not is nowhere close to a macro system.
I'd wager that's because no one has written tooling to make it compelling to the common programmer. Same with release management for a long time, and hot code reloading. I'd understand if you said that basic substitution macros are nowhere close to actual AST macros, but Erlang has far more than that.
Take a look at Elixir's agents or tasks and explain how it doesn't lead to more readable and cleaner code than the GenServer equivalent in Erlang for the cases they fit.
Those are sugar. It's not like you can't define your own behaviors in Erlang. People do it all the time, there's so many good libraries that go beyond stock OTP. I should really switch an entire language because of default libraries?
This sentence is specially ironic given that Erlang inherits from Prolog, which is quite different semantically from Erlang
Only traces. The Prolog influence of Erlang is severely overrated by a lot of people these days.
Also Erlang is pretty much a very dynamic language.
It ain't no Smalltalk. The runtime is very dynamic, and the typing is loose, but the Erlang language itself not so much, which I think is a strength.
I am a Haskell developer, I hate Ruby syntax and I programmed Erlang for a year.
> I'd understand if you said that basic substitution macros are nowhere close to actual AST macros, but Erlang has far more than that.
Fair point.
> Those are sugar. It's not like you can't define your own behaviors in Erlang. People do it all the time, there's so many good libraries that go beyond stock OTP.
There is a very strong point in providing those as default. If Erlang didn't ship with a gen_server, we would see hundreds of different gen_server implementations and no real consensus. By providing one, all Elixir developers are familiar with it.
In a way, you could define everything Elixir provides as a sugar, after all, it runs in the same VM. Sure, an Erlang library could provide all unicode manipulation functions... but having it all sorted out for me is a great deal. The same way Erlang solves many other things which makes it attractive to many.
That leads me to...
> I should really switch an entire language because of default libraries?
No. But if it provides a really good standard library altogether (unicode, structs, enumerable, etc) with an excellent tooling and powerful abstractions (like protocols), then surely yes.
But if it provides a really good standard library altogether (unicode, structs, enumerable, etc) with an excellent tooling and powerful abstractions (like protocols), then surely yes.
I can't comment on excellent tooling. Language-specific package managers never tend to be excellent, which is why I appreciate the limited scope of a tool like rebar.
Again, you are overvaluing a language based on the libraries it exports, rather than on its true a priori merits. Some languages are designed for intense extensibility and expressiveness, like Forth. An argument based on laundry listing abstractions to dissuade someone from using it would be rightfully dismissed as nonsense, since it is their prerogative to define the threshold of abstraction they need.
Furthermore, I've noticed that people who tend to promote languages based on the mere reductionist listing of abstractions tend to not understand those abstractions well themselves, treating it as dark wizardry.
Erlang is definitely malleable to reasonable extensibility. See Erlando which adds Miranda/Haskell-like monadic patterns to Erlang.
Except I am not. What would be Erlang really without OTP? Would you really want to implement all the building blocks in every new project? You are dismissing the importance behind stdlib while defending a language that is known specially because of its standard library (Erlang/OTP).
Also rebar3 is pretty much the same in scope as Mix (elixir tool). Which proves the point you are criticizing Elixir while using the same criteria to praise Erlang.
I am not saying Elixir is better or worse, just pointing you are extremely biased in your comments.
A lot of Elixir folks try to claim that the syntax doesn't matter. They're lying to themselves: of course the syntax matters. Not only is it much easier and more consistent for the human brain to parse (even more so than Ruby, in my opinion; unlike Ruby, everything that should take a block - like 'def' and 'defmodule' - do (pun intended) take a block), but it also goes above and beyond what Erlang offers with things like its pipe operator ('|>'), macro support, defaulting to binary strings (if you use double-quotes; single quotes are Erlang-style lists of characters, which - while they have their uses (aside from the obvious interoperability with Erlang code) - aren't really as efficient), and (in my observation) greater consistentcy between what you can do in the REPL ('iex') and what you can do in actual source files.
They're both great languages, but I think Elixir is a bit more refined, learning from Erlang's advantages and disadvantages and improving on them. It's basically what you get if you watch "Erlang The Movie II: The Sequel" [0] and actually try to write a language for Ruby hipsters with excellent taste in noserings while humming along to Bananarama :)
Don't forget LFE (Lisp Flavored Erlang), if you prefer a Lisp syntax to a Ruby syntax that runs on the BEAM, as I do, although Elixir has great momentum right now.
I've been doing full-time Erlang for five years, and I personally prefer Elixir.
Elixir is semantically close to Erlang the language, and allows you to take advantage of all the great benefits of Erlang/OTP.
It's benefit is dev's productivity. Creating OTP applications and releases is simpler, and there are tools in the language (e.g. macros, polymorphism via protocols, tidier stdlib), and around it (e.g. Hex package manager, mix tool, doc tests) that make developers' life simpler.
All of this is possible in plain Erlang, but it's more cumbersome, and sometimes requires home-brewed solutions.
Notice that I'm not discussing syntax at all, because it (mostly) doesn't matter. I actually like the Prologness of Erlang. What I dislike is that some chores require more of my time and yak shaving, compared to Elixir.
My impression is that Erlang/Elixir is excellent at the kind of decentralized networked services that people usually use it for, but less ideal for many other things. What's your experience with Erlang as a "day to day" language for more mundane stuff?
For example, a lot of my work tends to revolve around working with data. Processing large batches of data, parsing (often it comes in the shape of XML), transforming, filtering, ingesting it into databases, and so on. I can do this easily in Ruby, but performance issues has driven me to use Node.js or Go for new projects. With Go it's ridiculously easy to build efficient pipes that can parallelize each step to my liking, backpressure included. It's also trivial to build small command-line tools as well as specialized daemons. I have a world of libraries (and bindings to C libraries) at my disposal: AWS, image processing, transcoding, PostgreSQL, XML, JSON, it's all there. Go is also decent at Unicode and string manipulation.
I'm not wild about Go's performance, and everything I have seen of Erlang indicates that its performance is closer to that of Ruby or Node.js. Any comments here? Whenever I need to fire up anything related to batch processing in Ruby or Node.js, things take forever. Erlang's advantage here might be that it's easier to spawn remote processes to parallelize the workload.
Coming from an Erlang background, I found it very easy to get started with Elixir, it has the same underlying concepts and power as Erlang. Elixir takes it to the next level, though. The syntax eliminates annoyances in the Erlang system, e.g. having to fool around with punctuation and work with binary strings. The Elixir standard library gets rid of inconsistencies in the Erlang libraries and it is organized to allow easy chaining via the |> operator. Then it has features like protocols which give the encapsulation and polymorphism of OO without needing objects. And finally we have macros, which are the "right way" to do metaprogramming, allowing ease of use at a Rails level without the mess underneath.
Another big thing is that the Elixir community focuses on ease of use and out of box experience the way the Rails community did. So it's easy to get started and all the pieces generally fit together well, e.g. the mix build tool works great, as does the hex package manager, and relx release builder. With Erlang it's more DIY. We have recently converted a big Erlang project to use mix as the build tool, and it just eliminated a bunch of cruft. The interop between Elixir and Erlang is easy. So you get the best of both worlds, the ease of use of Elixir with the power of Erlang, with the highly mature runtime and libraries. And with Phoenix we get a web framework with world class ease of use.
227 comments
[ 1.7 ms ] story [ 291 ms ] threadI'm pretty excited about Elixir and Phoenix. Building on Erlang's OTP should mean scaling can be fairly transparent.
Personally I've got a few books on elixir (one written by you), but I'd like to get as many resources as possible for Phoenix.
I like the screenshot of htop on the front page with all CPUs working along. And a shoutout to the Erlang's Observer tool as well, to inspect the running system and show process dependencies.
The Phoenix website is hosted on https://readme.io/, it seems that it uses client side rendering for posts.
Edit: Not that you can't use Phoenix without realtime capabilities, but a lot of the good stuff in Phoenix is around Channels.
It's also worth noting that Ecto [1], the core-maintained Elixir ORM-like package, also hit v1 earlier this week and has backends for dealing with: PostgreSQL, MySQL, MSSQL, SQLite3 & MongoDB.
[1] https://github.com/elixir-lang/ecto
As someone who has used lots of ORMs I find the switch to a libary like Ecto very refreshing. It has an intuitive and very composable querying API and friendly DSLs for defining schemas and validations. These are the baseline features of any database/modeling library and Ecto satisfies them nicely.
But by far my favorite feature that has come in handy is that Ecto's concept of Repos does not couple you to a specific database. Unlike traditional ORMs that couple your objects to a specific database (read: the my_cool_app database in MySQL or Postgres) it's easy to support different databases within the same type of RDBMS or different RDBMS entirely. Since all querying in Ecto goes through Repo modules all you need to do is just create more Repo modules and configure them accordingly.
For some people this feature might not sound useful but if you've ever worked on an Enterprise or older app with multiple data sources or want to switch from MySQL to Postgres, this is a killer feature. Doing this with Rails' ActiveRecord is ugly, buggy, a pain and will bring you to your knees during Rails upgrades any time there are major changes in ActiveRecord.
Very exciting that they are branching out to support MongoDB as well. I'd love if they could support more untraditional Postgres operators for arrays and json (I guess there's always a tension between least common denominator and using the specialized features of each DB). You can get around it with partials, but it makes the code more messy.
Unfortunately, I don't have experience with using the ORMs you listed in anger so I can't make a direct comparison. Anecdotally, I have found it much nicer to use than Django's.
Sidekiq has been great as a background worker, but I'd like to try concurrency elsewhere.
Note that this was my first Elixir library and I was very much learning as I went along. Lot's of code that I want to refactor and extract.
Phoenix has really been exciting to use. It's a great way to get introduced into the OTP system from Erlang (plus all of Erlang's modules), it's incredibly fast, and the immutable data structures make it easy to reason about your concurrent code. I would strongly suggest giving it a try.
Getting my feet wet with a few side projects and am really loving Elixir and Phoenix. Performance is great and I don't miss too much compared to Rails. I still love Ruby and Rails, but will most likely default to Phoenix/Elixir for most future projects.
However "Developer productivity" seems like an excessively vague term, and would be hard to compare in any meaningful way.
Having said that, I've found it easy to get along with retuning JSON and the actual speed of responses is incredible. Completely anecdotal and unscientific but one service I recently converted from DRF to Phoenix saw drops in avg response time of 350ms to about 15ms.
i'm not aware of anyone running an erlang or elixir repl over http but it would be an interesting project
There are several key distinctions about Elixir vs the other languages you mentioned. These are things that are basically not going to happen in Ruby, Python, Go, Javascript, or etc.:
1) You get the benefits of Erlang/OTP as others have mentioned in their replies.
2) You also get the amazing macro capabilities (runtime code execution and runtime code generation, a la LISP) that Elixir brings to the table. Many of the language features of Elixir are written in macros in Elixir. The source to both Elixir and Phoenix are quite elegant and educational to browse, and demonstrate this runtime code generation aspect very well. It's straightforward in Elixir to introspect code, represent that code as data structures, manipulate those data structures, then generate or execute that code, as you can in LISP.
3) Immuatable data and functional style leads to better code in lots of ways. This is what really makes the benefits of OTP possible (updating the code without restarting the servers, easily migrating state between servers, and so on). But it also makes certain kinds of situations easier to understand and fix, since all state in the system can be expressed as parameters to functions.
Erlang provides great abstractions for building fault-tolerant, scalable, distributed, soft real-time systems. That's not to say you can't do it with Erlang, but Erlang does give some simple, yet very powerful tools for making developer's life easier.
Without Erlang you have to work harder to get similar effects. Again, it's not impossible but there's more burden on developers because the runtime provides less guarantees. I elaborated a bit on the topic in the promo interview for my book (http://www.infoq.com/articles/elixir-in-action-erlang-review).
I switched to Elixir and Phoenix last year and got the core of my app working.
It's funny though - the core is easier. But many freebies from Rails aren't there yet. So I still don't have password recovery emails or confirmation emails on signup done yet :)
Then you must create the login page.
Then the controller for authenticating. And then you need to ensure that the flow works with a test.
Then you need the email that actually activates the account, with the activation hash. So now you're setting up a mailer system, which Phoenix does not have by default.
Then people will want to recover passwords. So you need to write the logic for that. Oh, and the controllers and views. And routes.
And of course, you need to hash the password using some kind of encryption. Excrypt, comeonin, what have you. Choices choices choices.
You'll need a plug to act as the bouncer for your routes too, so nobody gets in where they shouldn't. So you'll have to write that.
You have to end-to-end test this, of course. And probably, if your business depends on it, get a couple other people to review the security of your system.
Simple. And takes a long time.
HTTP is pretty simple, but we use frameworks. SQL is pretty simple too, but we use Ecto now.
It's simple in its pieces, but I really don't wanna do all that work on every app. I'm lazy.
By the way, in case core team is reading, what's the motivation behind removing infer_model_view from the render functions?
I'm not on the core team, but speaking as an Elixir user, explicitness trumps all virtues.
Also Elixir will bring more people to the BEAM VM and take advantage of it, as I think it is a gem of engineering.
Rallying around one library sounds cool until you see that the top three competing solutions in another ecosystem each have more contributors and activity. Then you realize you're not in the elite ecosystem, just the smaller one that has one library like my tiny Texas hometown.
That being said, I do miss active_support though; Elixir's utility libraries (fox, pipe, croma, etc.) doesn't yet have all the easy automagic that made rails so simple to develop on.
1) Referring to DHH and others as a "our old masters" instinctively bothered me.
2) While I appreciate that Elixir and Phoenix have Rails connections and can learn from it, I'd prefer it not become just a place for Rails refugees where it turns into a huge circle jerk about how Rails is terrible and Phoenix is great (which happens all too often in communities).
Other than that, I agree. But we should start something new.
If you're building another Twitter I would still use Rails. You'll be much more productive.
On the other hand, if you need to run parallel tasks or have mission-critical (aka can't go down for anything) work to be done I think you'll find Elixir the perfect combination of Ruby's syntax and Erlang's power.
Just my $.02 - I'm having a blast with Elixir at the moment.
On the other hand, if you are just building another web app, Rails is the better choice...
As an example, Heroku uses cowboy (the erlang web server that Phoenix uses) for load-balancing incoming connections to all Heroku applications. The erlang VM (BEAM) is great for these types of highly concurrent, highly available, distributed tasks. The original use case for erlang was highly available phone switching for Ericsson.
To overcome the lack, I've used Resque (or beanstalkd in PHP, which has the exact same problem) as a background job manager, but then I had to write my own layer and rely on the database to handle the 'job' result.
Which parts of the framework leverage the concurrency model, other than the routing/request handling part?
I just start another process when you join a channel, and that process sets up the changefeed and pushes changes to the client in the form of HTML, allowing messages to be received and processed by the channel. You can watch the full presentation here: https://www.youtube.com/watch?v=aWaleoYD1Ro Slides: http://www.slideshare.net/bbhoss/otp-phoenix-channels-rethin...
Another example is sending email. In Rails, you need to have something like Sidekiq (or now Activejob) to be able to background the job so it doesn't block the response to the client. In Phoenix, you can simply spawn a process to do the work and move on. Sure, you might want a system like exq to keep track of things a bit better, but ultimately the concurrency primitives provides by Erlang/Elixir allow you to do everything you need.
I'll have a look at the slides
My understanding is that the cheap processes of Elixir would mean we could just keep a connection open to that user if we wanted to. Similarly, no need for a background processing framework like ActiveJob; just use processes.
And this works across the whole architecture. One of our projects right now is a mobile medical application for medical where caregivers communicate in real time with a number of patients. We have the mobile app talking to the server using a REST API and real time messaging for chat. The caregivers can communicate with the server using a web application with integrated web chat or via an XMPP client. And we have the normal public web and admin CRUD. All via a single server process in a single language. This is what Elixir/Phoenix was made for, it enables a new generation of modern apps.
http://www.phoenixframework.org/blog seems to point to the most recent post.
[1] http://www.firebirdsql.org/
I'd really love something built on erlang because of all the theoretical problems that just don't happen because of the way it's built.
> Phoenix is set to take on the world whether you're building APIs, HTML5 applications, or network services for native devices.
My NDC Oslo talk (linked in this thread) would answer your questions if you have the time to watch it. I give a high-level overview of Phoenix, Elixir, and the Erlang virtual machine and the virtues of how it all fits together. I'll try to get back later with a broader overview.
Sure it is, but "framework for building apps using language X which is run by virtual machine Y" is the basic pattern for JavaScript, Clojure, Scala, Java, and others. There are a lot of them, they have varying levels of integration.
Can I build a discussion forum in Phoenix? Sure, it has all the tools. Can I build it using PHP or Ruby? Sure those have tools too. Can I create an integrated IDE with my langauge and my execution environment? Sure we can do that too like Light Table.
So is it just Visual Basic all over again? Thinking of it that way is probably not conducive to polite conversation :-) but in many ways it is. We have a scripted language (Elixir), a virtual machine (Erlang), a "window" system (HTML5), and a set of APIs we can call on.
That is great, doesn't solve a new problem but solves an existing problem in a new way. And I watched Chris' talk and read the documentation, and I still don't feel like I have a good feel for why its better than what came before.
One thing it does do is allow scalability in a pretty straight-forward, integrated way.
There are lots of "new" problems with respect to changing conditions in our day to day lives. Here are a few
- Identity management across Internet and non-Internet properties
- Configuration, control, auditing, and monitoring of billions of Beacon level devices
- Zero knowledge proofs as a technique for anonymous and no repudiated purchases online
- "home" level cloud services for local and on the road implementation of always available services (mail, journaling, calendaring, Etc.)
- Reliable third party payment systems (somewhat of an old system but one that benefits from revisiting with current technology from time to time)
- Navigation and cartography tools for people in disconnected regions of the planet.
- Civil process augmentation with automation and authentication.
- Connectivity as a tax payer civic utility, without an editorial bias.
-Dynamic skills assessment for students in the presence of confounding factors (mostly remote access)
- Low friction capital markets for charitable giving (think Watsi but for everything, and with better controls than 'GoFundMe')
- Providing civic services for indigenous homeless populations.
I could go on, there are lots and lots of problems. But to be clear it isn't a criticism of Phoenix that they are not solving a new problem, the feedback was that there are lots of solutions to the general form of problem they are solving and, as feedback on this announcement, I was trying to learn from their materials how they were different (and presumptively better) than those other solutions. I'm still looking for that summary somewhere.
I couldn't find anything in the docs.
https://github.com/trenpixster/addict
https://github.com/opendrops/passport
Also here's a nice blog post that was in the elixir newsletter that may help!
http://nithinbekal.com/posts/phoenix-authentication/
I'm looking into using Erlang for a new project that requires extensive scaling and concurrency and am coming from a functional background so may be more comfortable with the traditional Erlang syntax. However it seems that perhaps more development and activity is happening on the Elixir side of things and it may be more productive in terms of tooling, libraries (such as Phoenix and Ecto), and support.
Thanks!
Erlang developer tooling does need work. But we are getting there, we have a new build tool http://www.rebar3.org/ that also combines forces with Elixir for the package management https://github.com/hexpm/rebar3_hex
The syntax is nicer, but that's just a bonus. The real game-changer to me about Elixir vs Erlang is its macro system. This gives you runtime code execution and runtime code generation, similar to what makes LISP to powerful.
There's a large amount of boilerplate involved in creating an OTP server, as you know if you've done any Erlang. Elixir's macro capabilities completely eliminate all the boilerplate.
The source to both Elixir and Phoenix are quite elegant and educational to browse, and demonstrate this runtime code generation aspect very well. It's straightforward in Elixir to introspect code, represent that code as data structures, manipulate those data structures, then generate or execute that code, as you can in LISP.
Elixir also gives a number of excellent tools that streamline the support process over vanilla Erlang. For example, Elixir's runtime tooling automatically manages dependencies for you (similar to node's npm), and automatically maintains the application string that you need to provide for all OTP applications. It also has improved capabilities for testing, which are also made possible by the amazing macro generation capabilities.
> I'm looking into using Erlang for a new project that requires extensive scaling and concurrency and am coming from a functional background so may be more comfortable with the traditional Erlang syntax
Elixir's syntax is still just as functional. They support a regular if statement, unlike Erlang, but generally it's just as functional as Erlang. Elixir eliminates a number of needless chores from Erlang, such as having to end some lines of code with a comma, and others with a period, and then shuffling punctuation around whenever you add or remove lines of code. That's a task I used to do literally a hundred times a day in Erlang that I don't have to do at all any more.
I've looked at OTP the Elixir way and I do not see any real boilerplate reduction. The application-project dichotomy and the opinionated integration with a tool like Mix is also policy over mechanism.
rebar3 does fine dependency management given its constraints of having to unify packages coming from disparate sources.
The syntax is not nicer. It is a jarring conceptual mismatch to put Smalltalk-ish Ruby syntax over a language that eschews excessive monkey patching and dynamism like Erlang.
You can also do concurrency in Ruby. It is not the same as doing concurrency in Erlang though. The same way doing metaprogramming with syntax tools, parse transforms and what not is nowhere close to a macro system.
> I've looked at OTP the Elixir way and I do not see any real boilerplate reduction.
So please look again? Take a look at Elixir's agents or tasks and explain how it doesn't lead to more readable and cleaner code than the GenServer equivalent in Erlang for the cases they fit. You could maybe point other criticism but saying "no real boilerplate reduction" just shows you didn't really try or care to give it a try.
> It is a jarring conceptual mismatch to put Smalltalk-ish Ruby syntax over a language that eschews excessive monkey patching and dynamism like Erlang.
This sentence is specially ironic given that Erlang inherits from Prolog, which is quite different semantically from Erlang, instead of using the more tradicional ML families. Also Erlang is pretty much a very dynamic language.
I am a Haskell developer, I hate Ruby syntax and I programmed Erlang for a year. I would still choose Elixir over Erlang any day mostly because of the tooling, typeclass like polymorphism and the new abstractions (Task and Agent).
I'd wager that's because no one has written tooling to make it compelling to the common programmer. Same with release management for a long time, and hot code reloading. I'd understand if you said that basic substitution macros are nowhere close to actual AST macros, but Erlang has far more than that.
Take a look at Elixir's agents or tasks and explain how it doesn't lead to more readable and cleaner code than the GenServer equivalent in Erlang for the cases they fit.
Those are sugar. It's not like you can't define your own behaviors in Erlang. People do it all the time, there's so many good libraries that go beyond stock OTP. I should really switch an entire language because of default libraries?
This sentence is specially ironic given that Erlang inherits from Prolog, which is quite different semantically from Erlang
Only traces. The Prolog influence of Erlang is severely overrated by a lot of people these days.
Also Erlang is pretty much a very dynamic language.
It ain't no Smalltalk. The runtime is very dynamic, and the typing is loose, but the Erlang language itself not so much, which I think is a strength.
I am a Haskell developer, I hate Ruby syntax and I programmed Erlang for a year.
Good for you, chap.
Fair point.
> Those are sugar. It's not like you can't define your own behaviors in Erlang. People do it all the time, there's so many good libraries that go beyond stock OTP.
There is a very strong point in providing those as default. If Erlang didn't ship with a gen_server, we would see hundreds of different gen_server implementations and no real consensus. By providing one, all Elixir developers are familiar with it.
In a way, you could define everything Elixir provides as a sugar, after all, it runs in the same VM. Sure, an Erlang library could provide all unicode manipulation functions... but having it all sorted out for me is a great deal. The same way Erlang solves many other things which makes it attractive to many.
That leads me to...
> I should really switch an entire language because of default libraries?
No. But if it provides a really good standard library altogether (unicode, structs, enumerable, etc) with an excellent tooling and powerful abstractions (like protocols), then surely yes.
I can't comment on excellent tooling. Language-specific package managers never tend to be excellent, which is why I appreciate the limited scope of a tool like rebar.
Again, you are overvaluing a language based on the libraries it exports, rather than on its true a priori merits. Some languages are designed for intense extensibility and expressiveness, like Forth. An argument based on laundry listing abstractions to dissuade someone from using it would be rightfully dismissed as nonsense, since it is their prerogative to define the threshold of abstraction they need.
Furthermore, I've noticed that people who tend to promote languages based on the mere reductionist listing of abstractions tend to not understand those abstractions well themselves, treating it as dark wizardry.
Erlang is definitely malleable to reasonable extensibility. See Erlando which adds Miranda/Haskell-like monadic patterns to Erlang.
Also rebar3 is pretty much the same in scope as Mix (elixir tool). Which proves the point you are criticizing Elixir while using the same criteria to praise Erlang.
I am not saying Elixir is better or worse, just pointing you are extremely biased in your comments.
They're both great languages, but I think Elixir is a bit more refined, learning from Erlang's advantages and disadvantages and improving on them. It's basically what you get if you watch "Erlang The Movie II: The Sequel" [0] and actually try to write a language for Ruby hipsters with excellent taste in noserings while humming along to Bananarama :)
[0]: https://www.youtube.com/watch?v=rRbY3TMUcgQ
Elixir is semantically close to Erlang the language, and allows you to take advantage of all the great benefits of Erlang/OTP.
It's benefit is dev's productivity. Creating OTP applications and releases is simpler, and there are tools in the language (e.g. macros, polymorphism via protocols, tidier stdlib), and around it (e.g. Hex package manager, mix tool, doc tests) that make developers' life simpler.
All of this is possible in plain Erlang, but it's more cumbersome, and sometimes requires home-brewed solutions.
Notice that I'm not discussing syntax at all, because it (mostly) doesn't matter. I actually like the Prologness of Erlang. What I dislike is that some chores require more of my time and yak shaving, compared to Elixir.
For example, a lot of my work tends to revolve around working with data. Processing large batches of data, parsing (often it comes in the shape of XML), transforming, filtering, ingesting it into databases, and so on. I can do this easily in Ruby, but performance issues has driven me to use Node.js or Go for new projects. With Go it's ridiculously easy to build efficient pipes that can parallelize each step to my liking, backpressure included. It's also trivial to build small command-line tools as well as specialized daemons. I have a world of libraries (and bindings to C libraries) at my disposal: AWS, image processing, transcoding, PostgreSQL, XML, JSON, it's all there. Go is also decent at Unicode and string manipulation.
I'm not wild about Go's performance, and everything I have seen of Erlang indicates that its performance is closer to that of Ruby or Node.js. Any comments here? Whenever I need to fire up anything related to batch processing in Ruby or Node.js, things take forever. Erlang's advantage here might be that it's easier to spawn remote processes to parallelize the workload.
Another big thing is that the Elixir community focuses on ease of use and out of box experience the way the Rails community did. So it's easy to get started and all the pieces generally fit together well, e.g. the mix build tool works great, as does the hex package manager, and relx release builder. With Erlang it's more DIY. We have recently converted a big Erlang project to use mix as the build tool, and it just eliminated a bunch of cruft. The interop between Elixir and Erlang is easy. So you get the best of both worlds, the ease of use of Elixir with the power of Erlang, with the highly mature runtime and libraries. And with Phoenix we get a web framework with world class ease of use.