3 ms·
> but Erlang/beam code is not that fast. True, no doubt. You wanted a comparison why phoenix is faster than rails. And simply doing things at compile time redu
by anonyfox 10y ago
> but Erlang/beam code is not that fast.
True, no doubt. You wanted a comparison why phoenix is faster than rails. And simply doing things at compile time reduces work at runtime. In Ruby, all Metaprogramming must be done at runtime, for example via method_missing trickery (been there, done that).
> Ruby's templates are parsed into code that stays in memory, too, so it's not like they're re-parsed each and every time.
This is actually not the same. A single immutable blob of binary (elixir strings) which is shared throughout the whole application can leverage hardware caching better. Jose could answer this probably better than I can do.
> someone should dissect these things in a real-world-ish application to see what's actually true.
Moz.com recently had fun with Elixir [1]. You may also have a look at https://www.youtube.com/watch?v=OxhTQdcieQE https://www.youtube.com/watch?v=OxhTQdcieQE from latest RailsConf.
> The claim was 'fast' though
Well at least I know that BEAM processes are far lighter than eg: goroutines. Also there is a per-process GC, so no "stop the world", much smaller units for individual collects, and when a process finishes before the heap grows full, it can be discarded directly.
> maintainable, which seems curious given that there are no really old Phoenix apps out there
Fair enough.
Personally I'd not wait until a software stack is a decade old before even considering it. I have at least worked on Elixir/Phoenix projects for many months now on-off with multiple colleagues, and it was/is still pure joy. Aesthetically pleasing syntax helps (broken window syndrome I guess), plus functional programming style in general, plus phoenix' foundation in "plug" and the clear modularity. "Let it crash" with supervisors also is incredibly robust, and robustness in itself leads to less maintenance costs.
---
[1] https://moz.com/devblog/moz-analytics-db-free/ https://moz.com/devblog/moz-analytics-db-free/
- davidw 10y agoAll good points. As I keep saying, I'm an Erlang fan. I actually used it at my last job, and have used it on and off since 2004-ish. It definitely has some advantages, but I'm just curious where it's actually beating Rails, and with what kinds of workloads and test methodology and so on. Stuff like "Erlang processes are lighter" matters in some contexts, but not in a straight up speed contest. It matters a lot when you start trying to handle a bunch of concurrent connections, so maybe that's where we're getting some of the claims from.
- anonyfox 10y agoI'd say you really should have a look into https://www.youtube.com/watch?v=OxhTQdcieQE https://www.youtube.com/watch?v=OxhTQdcieQE . A really great presentation, including numbers and real world backup data, plus conceptual overviews.
- davidw 10y agoIt's pretty good, but a bit hype-y. Functional programming is not an 'antidote' to having to go back and read old code or necessarily understanding it easily. It references this: http://sorentwo.com/2016/02/02/caching-what-is-it-good-for.html http://sorentwo.com/2016/02/02/caching-what-is-it-good-for.h... Which is interesting, but I don't see source code. 1.5-2X is pretty believable, but quite a bit less than "12 times" - which someone quoted here.
- anonyfox 10y agoI can personally confirm above 10x improvements over rails, but can't Share the code :) Depends on what you're doing though. Seems to excel when having low CPU intensive workloads but high traffic pressure from my experience.