I've been a raving fan of vagrant 30 seconds after I learnt about it 1.5 years ago. Engine Yard has been fans. We use it and want our customers to use it.
Thank god you have kept working at it so diligently for these 2 years!
Three quotes, hopefully not out of useful context, that seem incongruous:
"Rubinius is about the join JRuby and MacRuby in the realm of GIL-less Ruby implementations"
"I spend my free time working on an alternative Ruby implementation which doesn’t use a GIL (MacRuby)"
"I respect Matz’ decision to keep the GIL even though, I would personally prefer to push the data safety responsibility to the developers. However, I do know that many Ruby developers would end up shooting themselves in the foot"
So developers using GIL-less MacRuby, JRuby and Rubinius are prone to foot shooting? I wish they'd blog about this more, I've never once heard a MacRuby or JRuby developer blog saying "I went back to MRI because I needed my Ruby code to be run more safely".
I can't speak for JRuby or Rubinius, but in MacRuby one of the main reasons that lack-of-GIL is not a more serious problem is because MacRuby has the Dispatch library (based on libdispatch, a.k.a. Grand Central Dispatch) which makes working with multiple threads safe again.
If you were to invoke Ruby's Thread library directly in MacRuby, you would find that things get crashy rather quickly!
We run heavily-threaded code in jruby in production, but we also test on MRI because it detects and explicitly fails on deadlocks rather than just locking up.
Ha, that's possibly true as a percentage of total fees. Hopefully the total fees paid to Engine Yard will always be a rounding error in the context of consulting fees! :)
We're investigating other benefits for our Development Partners too. Any thoughts?
What I meant by that was that we weren't giving away 500 hours on a micro or small instance. We've not found them very useful for Rails/Ruby web apps. It costs us more to give away 500 hours of mediums, but we think the experience is a lot better.
ruby 1.8.7 is required for Rails 3; so Leopard/10.5 users need to install ruby 1.8.7 manually to get started as if they didn't have ruby installed at all, I think.
Another "side-by-side" route is via virtualization. I like http://vagrantup.com/ a lot for this. It allows you to share folders between the host + the guest OS. I'm interested in this route. Engine Yard is sponsoring Mitchell & his virtualization work to help it get more traction as part of a standard development toolset.
Either way, these are more convoluted "getting started" or "test drive" solutions. A 50Mb one-click installer that "just works" will hopefully help new Rails developers fall in love with Rails first and foremostly.
For the first release we wanted a stack of projects that "just worked", rather than the latest release of everything. We have a lot more confidence that a new developer to Rails, if using Ruby 1.8.7 from RubyInstaller will have a good development experience, today.
The intent is to upgrade RailsInstaller to Ruby 1.9.2 definitely. For the first release, we went with 1.8.7 to maximize the likelihood of pleasant experiences.
I'd like an integration test suite around RailsInstaller for common use cases of Rails (and other common ecosystem tools, like git). That might go hand in hand with the promotion of ruby 1.9.2 on Windows.
Over the last year I've done a few workshops for folks on Windows and I can tell you that you are spot on with your dicision to use 1.8.7 for now. It's so much more stable on Windows. The target audience for this package doesn't understand the various nuances that exist with Ruby, and really just expects things to work. With 1.9.2, I can get a newbie through an introductory class and tutorial, but as soon as they go outside and try to follow a RailsCast with a newer library, stuff starts getting weird.
I hope that this increases visibility on Windows so that gem maintainers will pay more attention to that audience when developing and improving their libraries.
