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

121–130 of 225 posts

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

#121

Post by asdf1234 »

percept wrote: post #72
davidw wrote: post #52

Earlier quoted context omitted.

I would love to see someone take a deep dive into why their Phoenix thing is "so much faster" than with Rails. I mean really look at the whole stack from the VM, to different pieces of the framework like views and DB interaction. Erlang definitely does concurrency well, but it is not that much faster than Ruby in terms of "raw speed". I'd be fascinated to see someone actually do the work and look at where Phoenix is…

I was a bit surprised by its performance in the last TechEmpower benchmarks: roughly equivalent to Rails and other Ruby-based solutions (PHP, too). It could be a case of not yet being optimized for the tests, but I was expecting much more impressive numbers out of the box (particularly after the full-court press on the boards and blogs).

The Phoenix tests had a ton of errors and there was no preview run so whoever submitted them wasn't able to fix them. This has happened with a bunch of different languages/frameworks in the past and until the errors in the implementation are sorted out the benchmarks are basically meaningless.

Chris McCord talks about it here https://www.reddit.com/r/elixir/comments/48ke69/any_reason_w...

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

#122

Post by desdiv »

rdtsc wrote: post #103
cutler wrote: post #92

Earlier quoted context omitted.

Elixir has no native array syntax nor any array functions in the stlib so arrays are basically second class citizens rather than completely absent. Ask not why I need them but why anyone might need them if the Elixir is supposed to be a general purpose language. Why does Clojure need them or Ruby or Python (lists)? If I want to process data as a large indexed array Elixir isn't going to help me and some Elixir devs h…

> Why does Clojure need them or Ruby or Python (lists)? So you want a list it seems > l=[1,2,3] > [h | t] = l [1, 2, 3] > h 1 > t [2, 3] > If I want to process data as a large indexed array Elixir isn't going to help me But neither will Python. You'd want a large indexed array you probably want numpy. See now you are revealing a bit more about your usecase that's helpful. So you have large amount of data and want to…

>But neither will Python. You'd want a large indexed array you probably want numpy.

Python comes with array.array¹ natively.

¹ https://docs.python.org/3/library/array.html#array.array

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

#123

Post by rafaelfranca »

abvdasker wrote: post #68
themgt wrote: post #7

Looks like a solid and and relatively straightforward upgrade from Rails 4.2. It's hard not to feel Rails has become a bit of a slow-moving behemoth though, with this release four years after 4.0. I've still got a couple clients using 3.2 from 2012 and things aren't that different. Smart money at this point seems like a significant portion of the Rails community could begin moving to Elixir/Phoenix over the coming ye…

The upgrade is anything but easy if an existing application uses protected attributes extensively (removed from Rails 5). Because protected attributes does a shitload of monkey patching it's hard to know exactly what side effects its removal might have, especially in any application that uses nested attributes for mass assignment/initialization of a model's relations.

I'm being working in this kind of application and there is no problem with the "shitload of monkey patching". Most of work was being done in the controller layer to filter the parameters. After you finished this you can safely remove the protected_attributes gem. To make this we created a migration sanitizer for the protected_attributes gem that I plan to integrate in the gem itself very soon.

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

#124

Post by rdtsc »

gtaylor wrote: post #112
rdtsc wrote: post #94

Earlier quoted context omitted.

> That saving of $150 is equivalent to one hour of pro dev work time. Fair point, unless you have more customers. Then it can start to add up quickly. And by customers it means requests as well. Being able to handle large traffic spikes and continous connections is a game change from what I found. Moreover. A huge benefit is using the BEAM VM, I use Erlang (but same VM) and I have seen major advantages being able to…

> Being able to handle large traffic spikes and continous connections is a game change from what I found This isn't specific to Elixir/Phoenix/Beam. > Some parts of the cluster would be crashing and restarting for a while, and there would be no need to wake everyone up Like any well-designed system that separates concerns. Again, this isn't language or framwork-specific. This stuff is what frustrates me most about th…

> these are all things that can easily be attained with just about any well-factored system on any number of languages/frameworks

Not sure what your point it. I shared my experience working with systems, you can share yours (if you have any).

Yes, you can write any of the stuff in assembly. Erlang, Java, Rust, all can be written in assembly. You can serve web pages in that too, and even create distributed system by twiddling bits directly in the network card's receive buffer.

> This stuff is what frustrates me most about the vocal early adopting crowd.

Lol, early adopters ;-) Erlang turned 30 this year. It is probably older than the median age of people reading this comment.

> Again, this isn't language or framwork-specific.

Again, point to where I said "nothing like this can be done in any other frameworks". Code reload -- can do it in Java. But you'll get paper cuts. Python -- can spawn an OS process to get fault isolation, but, can only spawn so many. Distribution -- spin another instance in AWS, talk gRPC with it, but now you are paying more money and have another library to maintain.

> But citing resilience, efficiency, scalability, and handling traffic spikes seems thin

Well would you prefer a whitepaper? It is an informal conversation. Do you ask for proof / benchmarks / whitepapers every time you talk to someone at a meetup? That must be fun.

But if you want a fun reference, pick up your smartphone, navigate to a web page. Does it work? Good. There is 50% chance it works because Erlang works. There you go, scalability, resilience and efficiency ;-) can share that at the next meetup's beer hour.

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

#125

Post by rdtsc »

desdiv wrote: post #122
rdtsc wrote: post #103

Earlier quoted context omitted.

> Why does Clojure need them or Ruby or Python (lists)? So you want a list it seems > l=[1,2,3] > [h | t] = l [1, 2, 3] > h 1 > t [2, 3] > If I want to process data as a large indexed array Elixir isn't going to help me But neither will Python. You'd want a large indexed array you probably want numpy. See now you are revealing a bit more about your usecase that's helpful. So you have large amount of data and want to…

>But neither will Python. You'd want a large indexed array you probably want numpy. Python comes with array.array¹ natively. ¹ https://docs.python.org/3/library/array.html#array.array

Original poster, specifically mentioned lists in Python, i.e. implying they wanted something equivalent to that. (Why does Clojure need them or Ruby or Python (lists)).

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

#127

Post by jblake »

Odd they didn't mention performance improvements in the blog post. From my understanding, there have been some massive gains (of which, some commits date back to early '15!) One of them which has been killing me, is that model schemas were not preloaded on app boot, which led to the first few dozen requests (depending on how many workers you have on Puma) perform 100+ sql queries and add over 1s to response times. Not only were they not preloaded, but they were not cached across ActiveRecord::Base.connection's

Good work rails team!

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

#128

Post by nine_k »

cutler wrote: post #101
nine_k wrote: post #93

Earlier quoted context omitted.

Does absence of arrays look a problem for you, while general immutability of most everything and message-based approach look totally normal and easy to grasp? I suspect that to use Elixir, you need to study a new way of doing things first. Then you'll see arrays in a different light.

I have studied Elixir and other functional languages such as Clojure where vectors are 1 of the 3 basic collection types so the "new way of doing things" isn't an issue for me. Elixir took a lot of inspiration from Clojure so the 2 languages are not that different.

Expectedly, per Clojure documentation, "Vectors support access to items by index in log32N hops". This means that a Clojure vector is essentially a tree-based map; a "true" array (as in C or Java) would have O(1) time for access by index.

I suspect that Elixir's maps are not different in this regard, as are Erlang's arrays, or maps in Haskell or OCaml. This is the canonical way to make an immutable map (see picture here: http://programmers.stackexchange.com/questions/195718/functi...).

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

#129

Post by jeremyevans »

stouset wrote: post #38
cortesoft wrote: post #18

Earlier quoted context omitted.

I like the sequel gem's syntax even better: Post.where(:id => 1).or(:id => 2)

Sequel's syntax is strictly less powerful, since Rails' accepts any scope instead of just a hash of conditions. Post.where(id: 1).or Post.joins(:author).where(author: { name: 'John' })

That doesn't appear to work:

    Post.where(id: 1).or Post.joins(:author).where(author: { name: 'John' })
    ArgumentError: Relation passed to #or must be structurally compatible. Incompatible values: [:joins, :references]
It appears that only the filter clauses are allowed to be different (similar errors if :select, :order, :group, :limit are different), in which case it's no more powerful than Sequel, just more of a pain to use. You can easily implement ActiveRecord's behavior in Sequel if you want to combine filter clauses for arbitrary datasets:

    ds = Post.where(id: 2)
    Post.where(id: 1).or(ds.opts[:where])
It's also interesting what happens if you mix where and having clauses (I'm not saying it doesn't make sense, but it may bite someone):

    Post.where(id: 1).or(Post.having(id: 2)).to_sql
    # SELECT "posts".* FROM "posts"

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

#130

Post by jeremyevans »

Raticide wrote: post #71
cortesoft wrote: post #18

Earlier quoted context omitted.

I like the sequel gem's syntax even better: Post.where(:id => 1).or(:id => 2)

This falls apart when you need multiple scopes as it can't tell how to group the 'AND' and 'OR's. The new Rails syntax avoids this problem.

That isn't a problem in Sequel, as you can pass a complex expression to #or, in which case it works as you would expect it to:

    Post.where(id: 1).or(Sequel.&({:id=>2}, {:name=>'Foo'}))
    # SELECT * FROM posts WHERE ((id = 1) OR ((id = 2) AND (name = 'Foo')))
Post reply on HN