5 ms·

I guess you can either see it as how much faster Cowboy is or how much more useful Rails is. It's nice if you have a lot of Erlang code already, but if you're m

by gozo 11y ago

I guess you can either see it as how much faster Cowboy is or how much more useful Rails is. It's nice if you have a lot of Erlang code already, but if you're making a web application from scratch, performance is pretty far down the list and I would stick to the half dozen stacks that are proven. Erlang can make sense sometimes, but it's probably not(!) comparable to Rails in those cases. Edit: Eh, I forgot a "not" in the last sentence, which is now added.

deleted 11y ago
[deleted]
digitalzombie 11y ago
Cowboy could serve API/data stuff instead. 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.
- simoncion 11y ago
  > Cowboy could serve API/data stuff instead. > RoR is productive for website/web apps. Phoenix [0] uses Cowboy as its HTTP server. [0] http://www.phoenixframework.org/ http://www.phoenixframework.org/
- IsTom 11y ago
  At company I work at we've got an application or two that have Erlang backend and a RoR frontend. It works pretty well IMO.
simoncion 11y ago
> Erlang can make sense sometimes, but it's probably not(!) comparable to Rails in those cases. 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.)
- deleted 11y ago
  [deleted]
technion 11y ago
Yeah don't get me wrong, this wasn't some blog spam about "why I don't use Rails". 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.
perishabledave 11y ago
The Phoenix Framework uses Cowboy at its core along with a Rack like middleware called Plug. There isn't much bloat in the stack so I'd assume performance is quite close to bare bones Cowboy. It doesn't quite have everything that Rails does, but it's getting there and fast!
pjmlp 11y ago
One lesson I took from the first .com wave in the early 2000 was never to use a scripting language for application software again. 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.
- go1979 11y ago
  I had to look this up so pasting what I found here: AOT = head of time compilation. https://en.wikipedia.org/wiki/Ahead-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.
  - pjmlp 11y ago
    My point was about using Ruby not Erlang. I know Erlang quite well. It seems my post came out badly.
- simoncion 11y ago
  > One lesson I took from the first .com wave in the early 2000 was never to use a scripting language for application software again. 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#L176 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 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#L731 https://github.com/davisp/jiffy/blob/master/c_src/decoder.c#... [1] http://www.erlang.org/doc/tutorial/nif.html http://www.erlang.org/doc/tutorial/nif.html
tbrooks 11y ago
Fortunately, you don't have to make the choice between performance and productivity any longer. Elixir and Phoenix give you the great productivity and the performance of being run on the Erlang VM.
- pmontra 11y ago
  Almost. I believe that half of the people that approach Phoenix coming from Rails stop when they realize there isn't any registration and authentication framework as good as Devise. The closest match is Addict but it covers only the basics and requires too much work. If one has to write his own product that could be OK. If one has to code for a customer it erodes the profit.
  - tbrooks 11y ago
    I thought the same thing too. A couple responses: 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. (1) http://hexdocs.pm/plug/extra-readme.html http://hexdocs.pm/plug/extra-readme.html
    - gozo 11y ago
      I'm not so concerned by the lack of libraries as with that no one seem to know the state of Elixir, Phoenix or BEAM. Security vulnerabilities are found all the time in established stacks and things like robustness, reliability, maintenance and growth are ongoing issues. Yes, BEAM is proven in enterprise use, but most of us don't have those resources. The first time I tried Elixir the welcome site broke, which wasn't a big deal, but it still didn't exactly instill a lot of confidence.

by gozo 11y ago

deleted 11y ago

[deleted]

digitalzombie 11y ago

Cowboy could serve API/data stuff instead. 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.

simoncion 11y ago
> Cowboy could serve API/data stuff instead. > RoR is productive for website/web apps. Phoenix [0] uses Cowboy as its HTTP server. [0] http://www.phoenixframework.org/ http://www.phoenixframework.org/
IsTom 11y ago
At company I work at we've got an application or two that have Erlang backend and a RoR frontend. It works pretty well IMO.

simoncion 11y ago

> Erlang can make sense sometimes, but it's probably not(!) comparable to Rails in those cases. 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.)

deleted 11y ago
[deleted]

technion 11y ago

Yeah don't get me wrong, this wasn't some blog spam about "why I don't use Rails". 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.

perishabledave 11y ago

The Phoenix Framework uses Cowboy at its core along with a Rack like middleware called Plug. There isn't much bloat in the stack so I'd assume performance is quite close to bare bones Cowboy. It doesn't quite have everything that Rails does, but it's getting there and fast!

pjmlp 11y ago

One lesson I took from the first .com wave in the early 2000 was never to use a scripting language for application software again. 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.

go1979 11y ago
I had to look this up so pasting what I found here: AOT = head of time compilation. https://en.wikipedia.org/wiki/Ahead-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.
- pjmlp 11y ago
  My point was about using Ruby not Erlang. I know Erlang quite well. It seems my post came out badly.
simoncion 11y ago
> One lesson I took from the first .com wave in the early 2000 was never to use a scripting language for application software again. 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#L176 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 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#L731 https://github.com/davisp/jiffy/blob/master/c_src/decoder.c#... [1] http://www.erlang.org/doc/tutorial/nif.html http://www.erlang.org/doc/tutorial/nif.html

tbrooks 11y ago

Fortunately, you don't have to make the choice between performance and productivity any longer. Elixir and Phoenix give you the great productivity and the performance of being run on the Erlang VM.

pmontra 11y ago
Almost. I believe that half of the people that approach Phoenix coming from Rails stop when they realize there isn't any registration and authentication framework as good as Devise. The closest match is Addict but it covers only the basics and requires too much work. If one has to write his own product that could be OK. If one has to code for a customer it erodes the profit.
- tbrooks 11y ago
  I thought the same thing too. A couple responses: 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. (1) http://hexdocs.pm/plug/extra-readme.html http://hexdocs.pm/plug/extra-readme.html
  - gozo 11y ago
    I'm not so concerned by the lack of libraries as with that no one seem to know the state of Elixir, Phoenix or BEAM. Security vulnerabilities are found all the time in established stacks and things like robustness, reliability, maintenance and growth are ongoing issues. Yes, BEAM is proven in enterprise use, but most of us don't have those resources. The first time I tried Elixir the welcome site broke, which wasn't a big deal, but it still didn't exactly instill a lot of confidence.