
I made a Phoenix webapp as a veteran Rails dev - stanislavb
https://www.reddit.com/r/elixir/comments/6bu3k6/made_a_phoenix_webapp_as_a_veteran_rails_dev/
======
preordained
What did he gain? Some performance? Did he need it, and was there no simpler
way to get it?

I get the premise, just trying things and having fun. But I get the impression
that in a lot (most?) scenarios this would be a lateral move at best. His last
comment about going with Phoenix instead of Rails for new projects, if he's
not just being kind, that seems like a major case of throwing out the baby
with the bath water.

Goodbye 10 years of experience, knowledge of pitfalls, etc...hello 1 month of
promise and years of gotchas and relearnings for small benefit?

~~~
mercurial
The performance question is a good one. Erlang has never been a performance
wonder, so I'd be surprised to hear that Elixir is noticeably faster than
Ruby.

~~~
Exuma
What are you talking about, its like an order of magnitude faster than ruby?
It might not be as fast as Go or Java or whatever, but its not even a
comparison to ruby, and particularly rails.

~~~
mercurial
Is it really that much faster? I mean, Rails is a separate problem, but I
would have put Erlang in the same perf bracket as Ruby/Perl/Python.

~~~
Exuma
Perhaps in raw computation its more similar, but based on the context of your
comment (and its parent), it seems more like you're comparing it to ruby+rails
in a real-life scenario (say, a web app). (The original comment was about
"what did he gain"?)

In that case, the multithreaded nature of Elixir and the VM there's no
comparison.

I tried searching for raw ruby+erlang benchmarks but couldnt find much in the
short time I looked.

------
dcwca
Is it merely coincidence that every time I hear about Phoenix it's from the
Rails community? Is it popular with people who haven't come to it from Rails?

~~~
danpalmer
As a Django dev, who has done bits of Rails, I felt it suffered from some of
the same problems with Rails that cause me to prefer Django. I'd love to see
what something inspired by the Django/Python community could be.

~~~
itbeho
Python/Django dev here that made the switch and love it. I would also like to
hear what your specific concerns were.

* edited for spelling

------
hartator
I am currently learning Elixir. Weirdly the thing I am blocking the most is
the functional aspect. I don't fully get why `List.get_elem list, 1` is
superior to `list[1]`?

(I know it seems a pretty obvious question, but I can't find satisfactory
answers that make sense to me at least.)

~~~
dozzie
Because it's not _superior_ , not on its own. You need context to tell which
one is better. Not to mention that you look too closely, so you miss higher-
level design that makes the difference between functional and imperative
languages.

~~~
hartator
Can you provide a minimal example where functional clearly overtake oop?

Bad oop is clearly inferior to good functional. ie React. But if OOP is able
to do functional as well, shouldn't OOP win on the long run?

~~~
easychris
I think it's also about the ecosystem. With Elixir all third party packages
etc. can be relied on having no side-effects / immutability.

If you try to code functional in an OOP language, you would have to make sure
that no third party modules (or coworkers accidentally) write code that
"misbehaves" in such aspects. Just like you currently have to make sure that
the Ruby code you use is threadsafe.

With immutability you gain all those features baked into Erlang/OTP
(scalability, reliability).

------
apeacox
A rails veteran that still heavily relies on ActiveRecord's callbacks sounds a
bit weird to me...

~~~
Lockyy
Do you have any resources to expand on the issues with AR callbacks? I'm
interested to read up on this.

~~~
jmcgough
AR callbacks can also make it harder to write tests.

------
jaequery
I'd like to see him try crystal next and how that compares

~~~
hartator
Crystal? What was your experience?

~~~
CrystalLangUser
I originally started as a ruby / rails dev and while I still do that, Crystal
is phenomenal to work with.

[https://crystal-lang.org/](https://crystal-lang.org/)

It's still a smaller community so frameworks and such are still being
developed. Currently there's a Sinatra inspired library, Kemal:

[https://github.com/kemalcr/kemal](https://github.com/kemalcr/kemal)

and then there's Kemalyst, which handles MVC and the like:

[https://github.com/kemalyst/kemalyst](https://github.com/kemalyst/kemalyst)

------
wgjordan
> Just the fact that app can utilize all cpu cores without you doing anything
> special is pretty damn awesome.

Rails apps can utilize all cpu cores without you doing anything special as
well (Since Rails 5 its default web-server is Puma, which is multi-process and
multi-threaded). I agree this fact is pretty damn awesome, but what (if any)
are the significant differences between Phoenix and Rails in this respect?

~~~
rlander
No it can't. It's technically impossible for a Rails app to utilize all cpu
cores because of the GIL. You're confusing two different things: the web
server and the actual Ruby app. The rails app is still limited by the GIL and,
therefore, runs within a single process.

~~~
wgjordan
So you're saying that when the OP talks about 'app can utilize all cpu cores',
he's specifically referring to individual requests spawning multiple
concurrent threads and therefore utilizing all CPU cores in isolation, as
opposed to the web server utilizing all CPU cores across multiple concurrent
requests by serving them on separate processes/threads? I would be interested
if the former was the case (and would be interested in practical examples),
but I highly doubt it.

~~~
rlander
Yes, the former. He's saying that his Elixir app should scale linearly to N
times faster on N cores processors (up to ~20 cores).

~~~
wgjordan
Rails can scale in this way too, by serving concurrent requests across
multiple forked worker-processes (note that the GIL doesn't prevent multiple
_processes_ from running Ruby code concurrently across multiple cores, only
multiple threads in a single process).

At first, it sounded like you were implying (by distinguishing between the web
server and 'the actual Ruby app') that Phoenix automatically parallelizes
portions of an _individual_ request across multiple threads/cores using some
special asynchronous dataflow-paradigm primitives or something. It would be
unique and truly awesome if that were true, but I still highly doubt it.

I don't doubt that Phoenix probably delivers orders-of-magnitude better
performance than Rails in many other respects, but 'utilizing all cpu cores
without you doing anything special' is nothing unique to Phoenix over Rails as
I understand it.

~~~
rlander
Well, by its nature a web request is sequential, so in 95% of the cases it's
just:

    
    
      process response -> deserialize -> put/get something from the DB -> send response
    
    

However, let's say you need to send off many requests to multiple external
services in order to respond to a particular request. These would be trivially
parallelized in Erlang.

Another thing to note is that, let's say Puma is running 8 workers and a bug
crashes the app. Every client connected to that worker is going to lose its
connection while that worker is restarted. In Erlang, you have one process for
each client so only one client notices the crash.

And finally, the overhead of starting multiple Ruby processes (in this case OS
processes) per Ruby interpreter is way, way larger than a starting multiple
Erlang processes. It's a difference of 300MB vs 2KB.

------
mempko
We are using Phoenix and elixir in a small service. Loving it so far. Super
fast and organized nicely.

