Edit: Eh, I forgot a "not" in the last sentence, which is now added.
I have no dog in this fight, but I've seen many people say that -despite the newness of the library "ecosystem"- they get an awful lot done with Elixir/Phoenix, and have a lot of fun doing it.
(Remember that Elixir is -like Erlang- a BEAM language. This means that Elixir gets the ease-of-understanding and interesting features of its syntax and has access to all Erlang software ever written. Similarly, any and all Elixir code can be called from Erlang with little trouble.)
Edit: (Also remember that the BEAM equivalent of Ruby is Elixir, and the (most popular?) BEAM equivalent of Rails is (AIUI) Phoenix. Phoenix uses Cowboy as its HTTP(S)/SPDY server.)
In fact I recommend it for a lot of cases. Problems that were solved years ago in Rails, like sane and default CSRF protection, are showing up in newly written PHP7 and Node applications that I'm seeing, because the things that Rails does are generally there for your own good.
I'm also aware it's not a direct comparison because Rails actually had an edge as far as its codebase.
The point I believe we can still take away from the original comment is - Cowboy is fast.
I'm very much looking forward to v2, the way it handles parameters is a much more natural fit imo.
Elixir and Phoenix give you the great productivity and the performance of being run on the Erlang VM.
1) The Elixir community is still in its infancy and the community is growing rapidly and flourishing. If the concern is there isn't an equivalent Elixir library for X gem, it's only a matter of time before it is. So please join!
2) I attended the Phoenix training at ElixirConf this week and an easy answer to registration and auth is "hey, write a plug". Once you dive into how straightforward plugs (1) and what (init/1, call/2) do, it's really simple.
You will appreciate the explicit nature of plugs compared to say, Rack middleware...
I'm rewriting a Rails app in Phoenix and overall, I've found it to be a really pleasant experience.
If you stick to writing code only in a BEAM language, you're insulated from all errors except for those of system resource exhaustion (edit: or -obviously- system hardware failure ;) ) or programmer logic errors. [0]
The parts of Elixir and other such projects that are written in another language that compiles down to native code, [1] are vulnerable to the usual array of issues endemic to the language selected.
> Yes, BEAM is proven in enterprise use, but most of us don't have those resources.
I'm not sure what you mean by this, and what concerns are implied by this statement. Would you care to expand this statement?
The WhatsApp folks have found that they got a lot done with Erlang with a small staff and (what is reported to be) very few machines when compared to the amount of work performed.
[0] Erlang can neither save you from your own faulty logic, nor can it add resources to your system. ;)
[1] Erlang provides a mechanism called NIF that lets you write performance-critical (or whatever) code in C or another language, and link it in to Erlang. From there, you can access your other-language code with from your Erlang code what appears to be a regular Erlang function call.
"Would you care to expand this statement?"
It seem proven enough if you have dedicated highly skilled developers. Not necessarily if you're a smaller startup that have to do a lot of other things and are relying on the ecosystem. With one of the more well know stacks you have a long history of not only security fixes, but knowledge about how to do things.
It kind of boils down to if I would implement say a payment system with the stack could I feel confident we wouldn't get compromised? Currently I have a lot higher confidence in e.g. Python + Django + Nginx than Elixir + Phoenix + Cowboy.
That said, I'm still playing around with it.
So, the following disjointed commentary might be entirely superfluous. It also makes no mention of Elixir or Phoenix, as I've not yet used them:
AFAIK, everything shipped in Erlang/OTP has a test suite that you can run and -if you've the time and technical chops- inspect and evaluate for completeness and correctness.
Given that the Erlang community tends to be concerned about safety and reliability, I have substantially more confidence in the correctness of some random Erlang library on Github than of some random JavaScript (or -ye gods- Perl) library. ;)
Given that neither Cowboy nor Ranch appear to make use of any NIFs, I would be fairly confident in their safety in the face of garbage or malicious input.
The erlang-questions mailing list is a good place to ask questions of folks who use Erlang professionally and non-professionally for a wide variety of things. I've heard that the Elixir equivalents are similarly helpful.
EDIT: I also believe Heroku's request routing system is built on Erlang.
RoR is productive for website/web apps.
I mean looking at just request per sec that metric would be much better for something like API/data serving app.
> RoR is productive for website/web apps.
Phoenix [0] uses Cowboy as its HTTP server.
Performance might not be on the top list, but when it comes usually a full re-write might be the only way out, as it was on our case.
Depending on the overall business situation such re-rewrite can have a huge impact on the company, due to shift on the development resources.
Since then, I only advice languages that have either JIT or AOT compilers available to them.
A couple of things:
Both Erlang and Python compile down to bytecode. Python compiles the first time you run a given script, Erlang won't execute Erlang source code; you must compile it to run it.
As go1979 mentions, Erlang has HiPE, which compiles Erlang down to the host platform's native code. If you find that your program is spending a lot of time in the Erlang code in a given module, you can -at any time- recompile that module with HiPE and reload it with either a system restart, or the hot code reloading machinery.
As an additional escape hatch, Erlang makes it rather easy to push performance-critical code out to a faster language -like C or C++ or whatever- and call that directly from Erlang. [0] Such code is called an NIF [1].
If most or all of what you're doing is hard-core number crunching, Erlang is probably not appropriate. If what you're doing requires tricky logic, needs to contain failures, or you're building a concurrent or distributed system, Erlang may very well be the right tool for the job.
[0] See an NIF as it is used https://github.com/davisp/jiffy/blob/master/src/jiffy.erl#L1... the corresponding C boilerplate to interface with Erlang https://github.com/davisp/jiffy/blob/master/c_src/jiffy.c and the implementation of the guts of that NIF: https://github.com/davisp/jiffy/blob/master/c_src/decoder.c#...
It seems my post came out badly.
Ah. Yeah, it did, a little. Next time, maybe mention one or two languages that you recommend and one or two languages that you don't, for context.
Oh, well. :)
AOT = head of time compilation. https://en.wikipedia.org/wiki/Ahead-of-time_compilation
Erlang's HiPE compiler is apparently AOT. The challenge seems to be dynamic typing. At points, it has to guess types. I assume compiled Python would have similar issues.