The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).

Basically what we were doing in Smalltalk for decades and trying to tell people about. (To a remarkable degree of push-back and vitriol.) Many years ago, one of our community pointed out that while it lost out as a mainstream platform, Smalltalk actually won the war of ideas. (It's taking quite a long time for everyone else to catch up, however. People keep thinking they've gotten there when they're still a good 1/3rd short.)

And I say that mostly as a compliment (though I still find the Ruby grammar atrocious from an implementation point of view).

I think there is something deep embodied here. Syntactic sugar items for languages are like features for libraries. It's been said that if everyone is completely happy with a library's features, the library maintainers haven't been doing their job.

Just throwing this out there, I know a bit about the difficulties this would entail, but: Is it plausible to have something like this running in production mode?

I mean, if I had a production Rack app running and could have pry-rescue (somehow) save its state and bubble the exception up normally, and later connect to the process and inspect what went wrong. Would something like this be feasible?

    class ApplicationController < ActionController::Base
      around_filter :pry_rescue if Rails.env == 'development'

      def pry_rescue
        Pry::rescue{ yield }
      end

  pry_rescue.rb
  require 'pry/rescue'
  class PryRescue
    def initialize(app)
      @app = app
    end

    def call(env)
      Pry::rescue{ @app.call(env) }
    end
  end

  application.rb
  config.middleware.use "PryRescue"

The only technical difference is that pry-rescue can catch exceptions raised at the C level (like NoMethodError, or ZeroDivisionError); but pry-rescue also has a much easier-to-learn API/UI. (Particularly, by only supporting catching unhandled exceptions, pry-rescue can avoid the need to predicate on which exceptions should be handled).

Fix for Chrome (Stylebot): http://goo.gl/9qoeF

Fix for Firefox (Stylish): http://goo.gl/6tkpz

However, having worked with both pry and ipython / ipdb, the difference in responsiveness and performance is quite significant and very noticeable between the two. ipython / ipdb feels faster by an order of magnitude. The most obvious difference is tab-completion. Perhaps this is enhanced even more comparing rails to django (the stacks I used pry and ipdb with, respectively)...

I guess at least tab-completion slowness is down to the fact that by its nature ruby has far many more functions that can run on any object than python, and hence more options to tab-complete?

However, regarding tab completion. I just did a quick test and noticed a small but important difference. Clicking tab in ipython instantly shows you the available completions. in pry, most of the time I have to click twice to see them! maybe that's what makes it feel slow to me.

If you're new to pry I recommend you check pry-remote & pry-debugger.