I'm very impressed with Rails 4, not just the overall level of improvements, but also the stability of what was released. To go more than 4 months without a patch is especially impressive for something like Rails.
I've dabbled with toy apps in 4 and have been very impressed with how smooth the change has been from 3 to 4. I haven't tried directly migrating a Rails 3 app so far (as 3.2.15 has been holding up quite well) but would anticipate it being far less of a hassle than moving from 2 to 3. AFAIK, Github is still on Rails 2
Thanks. Decisions were recently made to specifically make it easier to upgrade, even when it's worse for us: I removed a feature that we later reverted, for example. So it's nice to hear that it's appreciated.
<3
Benchmarks aren't, and never will be, the reason for using Ruby on Rails. Quite a bit would have to change in Ruby the language in order for the detractors of Rails to change their minds, and lets be honest, Rails wasn't built for those type of people anyway.
I agree. Ruby is slow for certain types of workloads, but for many kinds of workloads it simply doesn't matter, and Ruby is fast enough.
For workloads that require super high performance, one can simply use something else... Java, Node.js or whatever. Now that Phusion Passenger supports Node.js as well, it's very easy to write some parts of an app in Rails, and write other (performance-critical parts) of an app on Node.js, and deploy them together on a single server with ease.
A C extension in Ruby can be nothing more than an algorithm implementation accepting strings or numbers and returning such. Where you need proficiency in C is when you're building something substantial in it.
The problem with Node is, you have to load up a runtime. That can not only kill your performance gains, but actually make things slower.
I'd say standardize on a deployment model that leverages lots of nuts and bolts ruby doesn't care about.
Specifically, try using the apr (apache portable runtime), or leverage tomcat (which can use apr) + jruby + jndi jdbc connection pools.
Let rails be rails, your best bet for performance is either making the underlying ruby runtime better or leveraging things that are designed to be high performance.
The logic of the 4.0.0 way was better as the conceptual order of operation was correct. I don't have legacy app that needs major modification though.
Do you know off the top of your head if reorder will behave as order does in 4.0.0 (including nested scopes and associations)?
[Edit: It doesn't look like reorder does the job as it just drops existing orderings so you can't have a sequence of such calls. Don't think I like the reversion better to fix the API and the applications at migration to Rails 4 rather than persist the mistake.]
I would recommend 4 unless you have prior knowledge of an incompatible gem you can't live without. The benefits are worth it. I've built two small-scale Rails 4 apps now and all incompatible gems have been easily replaced with either custom code or other gems.
Can someone highlight the goodies on this patch? Sure we can read the changelogs entirely but a little bullet list of the best changes would be awesome. :)
Flask and Rails have different focuses. I've used both and like them both quite a bit, but I've found there is often a clear winner depending on the task at hand.
Flask is a microframework that often fits within one file and is probably more comparable to Sinatra than Rails. I've only ever used it for setting up really small webservices and stubbing webservices. It could certainly scale up to larger apps, but it doesn't give you a lot of direction in how best to do so.
Rails is a full-stack framework. Out of the box it gives you everything from the view to the database and strong conventions for where to place classes as your app grows. In general, it's more often compared to Django.
If you want to get started, my 'Learn Ruby on Rails' [1] covers Rails 4.0. It's for absolute beginners and good preparation for more advanced books. If you're more experienced, start with books by Hartl [2], Fernandez [3], Ruby [4], or Bigg [5].
This is my favorite new feature as well - I love how this stuff (including loading extensions) can be represented in the schema.rb now, so you don't have to switch to sql-format schemas.
Though we had a bit of fun in the past when multiple people are merging migrations at once, since it keeps version #s in the bottom of structure.sql and that can get out-of-whack if things aren't handled carefully, using structure.sql (config.active_record.schema_format :sql) is really not a bad way to handle a legacy schema/DB, depending on your process and requirements.
