Ruby on Rails 4.0.0.beta1 released

http://weblog.rubyonrails.org/2013/2/25/Rails-4-0-beta1/

by steveklabnik • 13 years ago

302 88 13 years ago

weblog.rubyonrails.org

jotto• 13 years ago

does threadsafe and ruby 2.0 mean we can create multiple instances with something like unicorn without forking the entire codebase?

andrewvc• 13 years ago

Funny thing about unicorn is, forking is core to its design. It may handle threading now, but when I last looked at its code fork() and traditional IPC via signals were core to its operation. Puma looks like the more thread-oriented choice these days.

nachteilig• 13 years ago

Last I looked Puma and jruby were the go-to options for threaded stuff.

FooBarWidget4• 13 years ago

Unicorn does not handle threading now. :) It never had, and according to its author never will.

Phusion Passenger Enterprise 4 is also thread-oriented.

atambo• 13 years ago

Ruby 2.0 still has the GIL so if you want to run a threaded web server you'll still need to be using rubinius or jruby.

jrochkind13• 13 years ago

ONLY if it's important to you that one process be able to run multiple threads on multiple CPU cores concurrently.

Even without this, there are MANY use cases where multi-threaded concurrent request dispatch makes a LOT of sense. For instance, the recent controversy about heroku routing, right?

With MRI or another interpreter with the GIL, you'd want to run one app process per CPU core -- but having each of those processes also do multi-threaded request handling can still even out latency (that is, avoid those awful ~95th+ percentile latencies in the heroku routing debacle), and increase overall throughput.

Especially if your app, like most but not all web apps, is more I/O bound than CPU bound (waiting on DB, disk, or external APIs).

nefasti• 13 years ago

Any reason ruby still has the GIL and not moved to a thread implementation?

jrochkind13• 13 years ago

I'm not sure what you mean by 'forking the entire codebase'.

Even if Rails3, though, Rails supported multi-threaded request dispatching IF you had an app server stack that supported it.

In Rails3, you just had to explicitly turn it on with `config.threadsafe!`. Rails4 makes that the default, always on. That's really the only difference. There are at least a few concurrency-related bugs that have been fixed in Rails4 (I'm actually not sure how many), but even Rails3 was officially documented to do multi-threaded concurrent request dispatch just fine. (Actually even Rails 2.2 was!)

Finding a mature, reliable, well-documented app server stack that supports multi-threaded concurrent request dispatch may be harder. I can not say which do and which don't, but there are at least some potential options (including puma, which, if I understand it right, has multi-threaded concurrent request handling as part of it's original core use case).

I AM hoping that Rails4's "multi-threaded request dispatch on by default" situation will make the community pay more attention to this use case, result in more app servers supporting it first-class robustly, and any remaining bugs around concurrency being found and fixed. While Rails3 was documented to support this anyway (since Rails 2.2!), it has been mostly ignored by the community, for some reason.

(Sadly, while Passenger Enterprise 4 will support multi-threaded concurrent request dispatch, the Passenger folks are intentionally reserving this feature for Enterprise, the free one won't)

andyl• 13 years ago

> Finding a mature, reliable, well-documented app server stack that supports multi-threaded concurrent request dispatch may be harder.

Try Jruby and Puma.

jeltz• 13 years ago

Ruby 2.0 means less memory usage with unicorn since the GC in Ruby 2.0 is copy on write friendly.

FooBarWidget4• 13 years ago

Memory savings would be similar to when you used Phusion Passenger or Unicorn in combination with Ruby Enterprise Edition, which also has a copy-on-write friendly GC.

FooBarWidget4• 13 years ago

You can already run multiple instances of Unicorn. In fact, Unicorn is designed to be a multi-process app server. When running multiple (single-threaded) processes you don't need to be thread-safe. This is the process model that Mongrel and (open source) Phusion Passenger use as well.

But what you probably meant with "multiple instances" is "multiple threads". You can't do multiple threads with Unicorn, it's explicitly designed not to handle multithreading. Instead you should use an app server that's capable of multithreading, e.g. Phusion Passenger Enterprise 4 which is hybrid multi-process/multithreaded.

The Phusion Passenger Enterprise 4 multithreaded stack is already being tested or used in production by multiple organizations. We've been using it in production for months without problems.

Also, multithreading does not require Ruby 2.0. Ruby 1.9 works just fine.

steveklabnik19• 13 years ago

Hello everyone! I am MEGA EXCITED for this release, as it's the first version in which I'm a committer. Wooo! In addition, 954 other intrepid Rubyists in total contributed to this release: http://contributors.rubyonrails.org/edge/contributors

Please note that this is a beta, not an rc, so some things may be a bit wonky. Please file an issue on GitHub and I will do everything I can to help you help us iron out all the kinks.

❤❤❤

(Also, I am on a plane and my battery is almost dead, so I may drop out of this thread soon. Ill read it when I'm home.)

grey-area4• 13 years ago

I'm curious to know if these examples of potential SQL injection tested against 3.2.11 have been dealt with in 4.0? Would be great to see these possible problems tidied up.

http://rails-sqli.org/

steveklabnik19• 13 years ago

I am not a member of the security team, but it's my understanding that all security patches were also applied against master where appropriate.

(The security team is a subset of the core team, in accordance with least privilege and all that.)

stiff3• 13 years ago

The examples here do not include SQL injection from known CVEs and are not vulnerabilites themselves, only potential misuses of the methods.

What would you like to have changed here? The methods work fine as long as you do not explicitly embed a user-supplied string in a larger SQL fragment.

batiste• 13 years ago

Rather dangerous stuff. I didn't know ActiveRecord would allow to shot yourself in the foot.

jaggederest3• 13 years ago

Proud to be on the contributor list for this one - any of you considering contributing, it's not hard at all, the team makes it really easy.

habosa• 13 years ago

Any pointers for getting started?

ctide• 13 years ago

I submitted my first contribution, but I never got a response: https://github.com/rails/rails/pull/8903 :(

I suppose it's a lot less of an issue now anyways, but in 3.2, using fetch with memcache with raw objects is super gross since you get totally incompatible responses depending on whether an item existed in cache or not.

george12• 13 years ago

As a rails user, thanks for your contributions! All you guys and gals rock!

newhouseb2• 13 years ago

I'm not a rubyist but I'm really excited for the russian-doll caching and really hope it catches on in other frameworks. Data dependency tracking makes everything from straight-up caching to real-time updates effortless and I think is one of the few places where an ORM can be really helpful (queue the two hard problems quote about cache-invalidation and naming things). Quora has been doing this since the beginning and I'm surprised it hasn't caught on in other open source (namely python) frameworks to the same degree, hopefully RoR will add some fuel to the fire.

clivestaples• 13 years ago

If I remember correctly, Adrian Holovaty said something about exploring pjax solutions for Django when he returned to help manage the project. It would be neat to hear more about his ideas if I missed them posted somewhere...

riffraff• 13 years ago

> (queue the two hard problems quote about cache-invalidation and naming things)

I think you meant "cue", otherwise please help a foreigner with this english expression's meaning.. queue onto what?

newhouseb2• 13 years ago

Yep, you're correct. "Queue" is just the programmer in me typing.

5vforest• 13 years ago

What is the "Rails way" of doing AJAX calls and updating the DOM? I've been embedding Backbone views in the parts of my app that are the most interactive, but I feel like there's gotta be a better way.

awj• 13 years ago

According to recent discussions, turbolinks. It's built into Rails 4 and essentially works by making a call out to the server to fetch raw html and replacing some/all of the DOM with the result.

Personally I just use Backbone and try to structure things in whatever way seems natural. It looks like there's been a lot of work done in integrating Ember.js if you want to look into that.

JuDue2• 13 years ago

Turbo links is more suited to traditional web pages.

Backbone for single page mini-apps.

xutopia2• 13 years ago

Rails 4 uses turbolinks. It is a mechanism that instead of loading a new page loads up the HTML via AJAX and replaces the entire content of the page without reloading all the resources(css, js, etc...)

So instead of having to deal with plenty of small ajax calls you just build an app as it would work in plain HTML and just use turbolinks to leverage AJAX.

merry-christmas2• 13 years ago

Funny that ASP.NET had the same thing, called Smart Navigation, back in 2003.

pmarsh• 13 years ago

But if two pages have the same resource URLs for their css, js, etc they should be cached by the browser so moving from page to page shouldn't be reloading them.

This does not seem like a super great idea, like merry-christmas mentioned too much like ASP.NET.

I'll do some reading on turbolinks and see if there's something super I'm missing.

steveklabnik19• 13 years ago

It just so happens that one of my major contributions to this release was writing a 'working with JavaScript in Rails' guide: http://edgeguides.rubyonrails.org/working_with_javascript_in...

Others mentioned Turbolinks, but they forgot about remote_form_for and friends.

If you _are_ building a full JavaScript application, Ember.js works really well with Rails + ActiveModel::Serializers. There might be some rough patches until Ember hits 1.0 final, but most of the pieces are in place.

jrochkind13• 13 years ago

Awesome, thanks so much for writing that guide.

JS in Rails had gotten confusing lately, with changes being made over time to supported options and 'golden paths', but insufficient docs on what Rails expected/recommended.

Thanks for working to rectify that!

_frog• 13 years ago

Just want to chime in and say how fantastically ActiveModel::Serializers and the Ember.js REST adapter work together. I built a project with them over the weekend and the experience was overwhelmingly frictionless to a degree I hadn't experienced doing this kind of thing in the past.

eCa• 13 years ago

Why is the answer on how to use Javascript to use Coffeescript? Does all RoRists use CS instead of JS, or is it considered best practice?

(I don't use either Ruby, RoR, Coffeescript or Ember.)

JuDue2• 13 years ago

Sorry for the naive question... But does this help Heroku's woes?

xutopia2• 13 years ago

Nope. The issue at Heroku is before the request has a chance to talk to the rails application. That is why so many people were annoyed that the reporting tool that analyzes speed of the rails application did not report the time lost.

mrmagooey• 13 years ago

Is there a Turbolinks equivalent for Django? Or something platform agnostic (I couldn't tell if that was the case with Turbolinks)?

steveklabnik19• 13 years ago

Turbolinks is 100% Coffeescript; you could easily add it to a Django application by copying the assets out of the gem: https://github.com/rails/turbolinks/blob/master/lib/assets/j...

tnorthcutt• 13 years ago

Since Turbolinks is a Ruby gem, it's not exactly platform agnostic :). Hopefully someone else has an answer for Django, but you might take a look at https://github.com/jacobian/django-pjax and http://www.youtube.com/watch?v=3ml88L39cng

Edit: aaand steveklabnik knows more about this than me; listen to him.

egonschiele• 13 years ago

How is live streaming implemented?

steveklabnik19• 13 years ago

https://github.com/rails/rails/blob/master/actionpack/lib/ac...

adml• 13 years ago

I am writing an upgrade handbook that covers the important deprecations and new features in detail: http://www.upgradingtorails4.com/

ghiculescu• 13 years ago

What's the recommended alternative to ActiveRecord Observers? I know they aren't perfect, but I wasn't a fan of cluttering my models with lots of after_commit - is there a better way?

timdorr2• 13 years ago

They are still maintained, they've just moved to a separate repo/plugin: https://github.com/rails/rails-observers

spohlenz• 13 years ago

One option would be to use a service object (e.g. UserCreator) which would encapsulate the action (saving a user) along with the action to be taken (delivering a signup email).

With external observers, it's not always obvious whether they are enabled or not. Service objects make this more explicit and are easier to test as well.

byroot2• 13 years ago

I don't know if it's recommended but for simple cases where I just want to trigger some methods on multiple models I just use a concern: https://gist.github.com/byroot/5036110

hayksaakian• 13 years ago

How well does rails 4 play with mongoid? Any breaking changes I should be aware of?

steveklabnik19• 13 years ago

I'm not sure, because I don't use it, but edge mongoid at least claims to be compatible: https://github.com/mongoid/mongoid/blob/master/mongoid.gemsp...

davidw• 13 years ago

Is the web socket story substantially the same? In other words, Rails just isn't that great a platform for it?

I think Rails is great, but this is one area where it's not a good choice.

steveklabnik19• 13 years ago

We don't do anything specific with WebSockets. ActionController::Live may be able to help you there, in theory, but I'm not incredibly educated on the subject, to be honest.

VeejayRampay• 13 years ago

The general opinion in the Rails ecosystem seems to be that WebSockets don't solve any real problems and that they are a toy.

The only mentions of WebSockets I've seen from people invested in Rails are mostly made of people actually deriding them and passive-aggressively making fun of people that use them or want to (generally in a bunch with MongoDB, Hadoop, Cassandra or other modern big data tools that don't fall naturally in the Rails ecosystem).

But then again, it's not like they have an infinite amount of time to invest into everything and anything and they worked on SSE for Rails 4 on top of shitloads of additional goodies, patched a lot of security issues so overall I'm pretty happy as an end-user.

DanielKehoe• 13 years ago

Here's an article that shows how to set up both Rails 3.2 and 4.0 with Ruby 2.0. Uses some new features of rvm. "With both versions on your machine, you’ll explore the new features of Rails 4.0 while continuing to develop projects with the most recent stable version."

http://railsapps.github.com/installing-rails.html

Ruby on Rails 4.0.0.beta1 released

Related Stories