141–150 of 225 posts
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…
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…
It sounds like you're undervaluing concurrency. Concurrency is huge for a web application. If you were say doing image manipulation or other DSP where you needed "raw speed" you'd want to choose a language like C, Go, Rust. But in a web application you're handling hundreds, thousands, to millions of requests per second; concurrency is crucial for that kind of throughput. A developer on my team did some quick benchmar…
Earlier quoted context omitted.
> 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 t…
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…
From what I've read in the comments so far, you won't see it thinking in terms of speed of Erlang vs Ruby. It sounds like the gains come from baked in behavior, so that "Rails + Redis" or "Rails + Redis + nginx" is equivalent to Phoenix alone. I'm still only reading about this, though. No Elixir experience here.
I used Erlang at the last place I worked and like it a lot, but Rails is pretty good too in my book.
This has been long awaited: Post.where('id = 1').or(Post.where('id = 2'))
Seriously, .or() always felt like a glaring omission.
Another implementation is Post.where(id: [1, 2]) which is SELECT * FROM posts WHERE id IN (1, 2). I guess a db would compile it into exactly the same code (dbs use different terms but that's what it is) but the performances could be different inside AR/Arel.
Earlier quoted context omitted.
I just dont see how ruby can overcome the vm disadvantage to be honest I don't know how mature it is, but couldn't jruby be the answer to this?
I use jRuby, which is great and an amazing piece of engineering. However, with Rails, you're only see about a 20% speed bump and out of the box it uses too much memory to run on Heroku's free tier. You'll also miss out on the gems with c extensions (for now I think that's about to change). Additionally, there seems to be a performance regression around includes and case statements. Your devops story can also be a bit…
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)
However there are other school of thoughts and not everybody likes the Rails way. It's fair and it's a big world with space for every opinion and tool.
Earlier quoted context omitted.
I'm still fairly new with Elixir/Phoenix (as I think most of us still are), but so far I feel intuitively that it's more maintainable and I admit that I don't have the experience or numbers to back that up yet. There are some things that you simply must use other tools for in Rails, because it can't maintain state like Erlang can. Once you start adding in these other things, you're no longer just a "Rails app" but yo…
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…
- 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 you get near instant templating, instead of the usual string processing on every request.
- dispatching code like the routing that must be done on every request is like rails a DSL, but actually a macro, that gets compiled down to basic pattern matches, which is extremely fast.
- the concurrency model is extremely lightweight, handling more requests and/or doing more stuff per request is much more efficient hardware-wise. Indirect performance gain.
Just a few points that have a very noticeably impact, there are probably more. It boils down to the erlang vm's concurrency and pattern matching performance, plus elixir's compile-time macros and the fact that they treat strings as immutable binaries.
I wish I had API mode 4 years ago
You could have! It was reverted, so we made https://github.com/rails-api in the meantime, and this was finally (literally four years later) pulled upstream now.
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…
Thank you so much Michael.