Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails 5.0: Action Cable, API mode, and more

weblog.rubyonrails.org

Post reply on HN
Print view View original

191–200 of 225 posts

Re: Rails 5.0: Action Cable, API mode, and more

#191

Post by anonyfox »

davidw wrote: post #190
anonyfox wrote: post #185

Earlier quoted context omitted.

Sure! But this time (tm) it's different. Phoenix is a direct drop-in replacement for rails, with a bunch of strong benefits on top. Getting productive for a rails developer should be 1-2 weeks max, since one already knows how the framework works conceptually. The truly cool stuff happens when one learns how stuff works beneath the surface. While you're around: Elixir/Erlang in itself is a rather slow language when it…

> direct drop-in replacement Uh... "Drop-in replacement is a term used in computer science and other fields. It refers to the ability to replace one hardware (or software) component with another one without any other code or configuration changes being required and resulting in no negative impacts." That's not the case at all with Phoenix, nice as it may be.

Point to you. I should have looked up the actual definition.

Re: Rails 5.0: Action Cable, API mode, and more

#193

Post by anonyfox »

davidw wrote: post #186
anonyfox wrote: post #148

Earlier quoted context omitted.

Some bigger details why phoenix is so fast despite erlang being a "slow" language: - macros: fancy syntax and "magic" can be resolved at compile-time. Less work to do on runtime. - templates: they get handled at compile-time, too, resulting in functions with blobs of binaries. This matters a lot, since a specific template-binary exists only once throughout the application and gets re-used whenever needed. This way yo…

> macros All well and good, but Erlang/beam code is not that fast. > templates 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. > routing Perhaps clever use of pattern matching helps here. But my point is: someone should dissect these things in a real-world-ish application to see what's actually true. > concurrency Yes, but let's be precise. Ever…

> 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 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/

Re: Rails 5.0: Action Cable, API mode, and more

#194

Post by kibibu »

albasha wrote: post #86

I am very jealous as a Django developer. They decided to keep Channels as a third-party package after all, maintained by a single guy :(

(Cynical mode engaged)

Here's why you shouldn't be jealous: https://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On...

There are still remote code execution and even SQL injection flaws being discovered in Rails.

The dreadful security record of Rails really seems like the elephant in the room.

Compare to Django https://www.cvedetails.com/product/18211/Djangoproject-Djang...

Re: Rails 5.0: Action Cable, API mode, and more

#195

Post by fantasticsid »

pmontra wrote: post #147
fantasticsid wrote: post #91

I actually don't like rails' convention over configuration school of thoughts. It makes everything implicit. For any large rails app it's difficult to reason about how things are working, unless you learn all the conventions by heart (by the way, these conventions don't seem to be documented well)

If you are a Rails developer you know all the conventions and they help you at finding code with only an editor and a file manager. No need of IDEs. It's very easy to learn a new application, unless the original developer wanted to be clever, which usually means that was one of his/her first Rails projects. However there are other school of thoughts and not everybody likes the Rails way. It's fair and it's a big worl…

I never learned 'all conventions'. There are countless cases where I had to dig into source code to find out how a certain feature is working/how it works with another feature/when the abstraction does not work the way I want

I guess being implicit just makes it harder to find out which part of abstraction is leaking when it happens..

But again I'm not a good rails programmer. I was just never a fan of how conventions play such a big part, and was not well documented.

Re: Rails 5.0: Action Cable, API mode, and more

#196

Post by davidw »

smss79 wrote: post #170
sams99 wrote: post #151

Earlier quoted context omitted.

jeez where are those numbers coming from :) For Discourse which we host in general we spend HALF the time in database calls and say 20-30% of the time in ActiveRecord bullshit. Lets say we erased all of the app cost using some magic, we would still only be saving 50%, so twice as fast, now erase some ORM bullshit, say another 50% faster, so at a super ambitious totally unrealistic setting we could be 4x faster. For a…

I would say languages that can leverage concurrency and do pooling well will generally put less pressure on the database for the same load. Rails in particular is very wasteful in terms of connection management, typically checking out the database connection for the duration of the whole request. If you have a machine with 4 cores, one of Rails deployments would start 4 processes each with 10 database connections. So…

These are good points, but they regard the system as a whole. Is that what's "12 times faster"? I don't like big claims without seeing some more detailed numbers and methodology.

Re: Rails 5.0: Action Cable, API mode, and more

#197

Post by davidw »

anonyfox wrote: post #193
davidw wrote: post #186

Earlier quoted context omitted.

> macros All well and good, but Erlang/beam code is not that fast. > templates 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. > routing Perhaps clever use of pattern matching helps here. But my point is: someone should dissect these things in a real-world-ish application to see what's actually true. > concurrency Yes, but let's be precise. Ever…

> 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…

All 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.

Re: Rails 5.0: Action Cable, API mode, and more

#198

Post by eric_h »

nirvdrum wrote: post #63
bdcravens wrote: post #45

Earlier quoted context omitted.

Every time I've explored alternatives to try to get those kinds of numbers, it seem the bottleneck is more in the database than the application server.

How granular are your measurements? I'm certainly not calling your experience into question. But I wanted to relay a cautionary tale of my own. On one project my team was convinced that Redis was our bottleneck. Profiling was showing that Redis calls were where the most time was spent. I spent some time looking at the redis-rb source and it does a lot of block nesting (4 or 5 levels for every call, IIRC). So, I tried…

The performance problems I've had with redis-rb were largely due to my accidentally using it in an improper environment (an event machine based asynchronous service). Replacing it with em-hiredis (and refactoring to use callbacks) drastically improved throughput for us.

In situations where a blocking redis client like redis-rb doesn't interfere with other running code (synchronous web requests), I've found zero performance issues with redis-rb (latency caused by redis is measured in single digits, usually < 5ms).

Re: Rails 5.0: Action Cable, API mode, and more

#199

Post by rozap »

anonyfox wrote: post #185
steveklabnik wrote: post #180

Earlier quoted context omitted.

I really like Elixir and Erlang, but haven't found he time to play with Phoenix. But... > You're right basically, but the migration wave from > rails to phoenix has noticeably started, and > it shows. People have previously said this about: * Clojure * Node * Go And lots of things before that.

Sure! But this time (tm) it's different. Phoenix is a direct drop-in replacement for rails, with a bunch of strong benefits on top. Getting productive for a rails developer should be 1-2 weeks max, since one already knows how the framework works conceptually. The truly cool stuff happens when one learns how stuff works beneath the surface. While you're around: Elixir/Erlang in itself is a rather slow language when it…

You might be interested in this project: https://github.com/hansihe/Rustler

Re: Rails 5.0: Action Cable, API mode, and more

#200

Post by jkulmala »

mhartl wrote: post #22

Looks like now's a good time to mention that the Ruby on Rails Tutorial book has already been updated for Rails 5: http://railstutorial.org/book Sales actually just launched on Tuesday (announcement here: https://news.learnenough.com/rails-5-edition-of-rails-tutori... ), and you can pick up your copy of the new 4th edition here: http://railstutorial.org/code/launch That link includes a 20% launch discount, which expi…

Michael, I learned Rails from your tutorial and started implementing my SaaS app the day I hit chapter 14. That's how I went from corporate Java slave to location-independent entrepreneur. Your tutorial is that good, it's all I needed.

Thank you so much for keeping the tutorial alive!

Post reply on HN