is it better to develop ruby on rails in a) windows b) linux or c) mac. why ?
edited :
the reason why i am asking this is that i heard that developing ruby on rails in windows is not as stable/good compared when you used ruby on rails in mac. (not sure though if that is true or not).
plus the fact that David Heinemeier Hansson (creator of Ruby on Rails) seems to be using Mac, so initial impressions seems to be Ruby on Rails applications and Mac goes well together.
Shouldn't matter, whatever you're most comfortable with. I've done all three.
I suppose Windows is a little uncomfortable because of not being unix-based, the CLI is a bit more clunky.
(But if you use a tool like NetBeans, you don't really even need the CLI much)
Doesn't matter, If you're a purist then your dev environment should as closely match your production enviroment as possible with regard to Operating System and version of the Ruby and Rails. But really it doesn't matter much.
Ruby on Rails works well on all platforms, but tool support varies. For instance, TextMate is a favorite editor amongst Rubyists, and it's Mac only. You'll be able to find lots of helpful tools for working with RoR in TextMate, so it might be best to do RoR development on a Mac.
I use Mac and Linux myself.
A Unix based system will offer you a path of lest resistance as all gems are available/compilable on these systems, which isn't as easy on a Windows machine. It's not impossible on Windows but you'll spend more time getting it to work rather in some cases rather than doing work.
Of those Unix systems my preferred is a Mac, it's got all the Unix power as well as all the interface niceties that can be lacking from your linux system, and of course I couldn't live without my daily dose of TextMate, so Mac it is.
Some gems work on Mac but not some flavors of Linux (such as gitjour when I last tried it).
Using a Mac might be good or bad, depending on whether you want to know that whatever you develop will be able to work on any other OS.
I recommend against using windows when developing an app that will later be deployed on a linux system. If you're developing an app for practice, Windows is fine.
The issue is that if you're aiming at linux, then you'll want to have a full stack on your development machine: a web server, a dbms, perhaps memcached, etc. While it is possible to load all of that onto windows (I've done it), it will take longer than on a linux machine, will be slower and you'll have more difficulty finding assistance when something doesn't work.
Also, you can run into gem and plugin support issues on windows. Eg \ instead of / for directory paths and other weirdness. While rubyists will try to be helpful, windows support is sometimes limited since most RoR work is done on Mac or Linux machines. Eg Capistrano has had problems running on Windows (they may be fixed now).
As an alternative, you can use Windows as your desktop machine, but use a linux machine as your development server for running the app. Any old pc will run linux just fine. Use samba to remotely access and edit the files from your windows machine. The linux machine does not need a display, you'll only use it remotely.
Just change your app's config/environments/development.rb to include
config.action_controller.consider_all_requests_local = true
so you can see stack traces from your browser running on your windows machine.
Regards,
Larry
I strongly advise you don't develop on Windows. Why? First, there are a lot of things that break on Windows with every upgrade and the majority of gem or plugin creators don't use windows so they don't care about windows and don't run tests on it(there are several big name people who have flat out said that windows is NOT their problem it's yours). You'll find the *nix vs Windows problems will bite you in the ass again and again. Pathnames slashes, minor differences in ssh implementations, console and font problems, rubygems, capistrano, etc...
What will end up happening after a while is that you will always have this voice in the back of your head every time you have to debug something saying "Is this a problem only on Windows?" and that little voice is a cost to you..using up some of your battery every single day.
Macs are more expensive in terms of upfront dollars (which sadly I don't have) and linux platforms are more expensive terms of spending a day or two trying to get your wireless to work but those are upfront one time costs. The nagging insecurity of using Windows for Rails development is an ongoing cost. At least until the community starts rejecting things that are not truly cross platform.
As an example look at cucumber. For some reason a test framework is dependent on a particular console configuration not available in windows. So to use it in Windows you have to change the font in your console and change the code page in your console. Otherwise the letter "a" disappears from all the output. Why? Because it works fine for *nix systems and gives you pretty colours (I think this is a huge flaw and very very poor design choice even if you ignore windows).
You'll also feel like the guy who farted in the elevator every time you bring up a windows issue.
I say all this as some who has to use windows for his development platform at the moment. Hey, what's that smell?
[late edit: Ruby is also about 3 times slower on windows. This will impact your willingness run your tests all the time and hurt your TDD feedback cycle]
I've done light rails development on both OSX and Linux (Ubuntu), and I found the differences to be almost imperceptible (in terms of ruby and rails... obviously the desktop environments are a lot different between the two OS's).
As others have said, most ruby/rails tutorials, gems, plugins, etc. are oriented toward Unix type systems, so I would assume there may be some annoying hiccups trying to do ruby/rails development in Windows, unless of course you're using IronRuby. :-)
A low hassle alternative for setting up a Unix environment for Rails development is to run one of the easier to use Linux distributions, like Ubuntu or Fedora under virtualization software like VMWare, VirtualBox, VirtualPC, etc.
I agree with many of the previous posts that Rails on Windows can be an issue. Its simply the case that many people developing for Rails are on Macs or Linux and as a result Windows bugs are not found, this is particularly an issue with plugins.
One issue with Rails is IDEs. TextMate on the Mac seems to be a popular choice, yet Linux and Windows options are pretty fragmented. Normally I wouldn't worry about this, but I have found that Rails becomes much more manageable when you have IDE support. In general there are lots of files located in a reasonably complex directory structure so having an IDE which allows you to easily find files your looking for is an awesome productivity boost.
Another thing you may want to consider is what your deployment environment looks like. For example, may people deploy there Rails apps on Linux servers. In that case, you may be able to skirt around bugs by developing on OS X, but unfortunately those bugs will crop up when you go to deploy your new software. That is the last place you want to be debugging code. Of course you should be testing your code in a staging environment first, but all too often people skip this step.
While searching for the answer to this question due to always having to hack my way around windows to things to work while developing in Ruby, I can say that if you have the option, use Linux or Mac. I've officially started using Ubuntu 9.04 as of today and here are the reasons why:
1) Can't do any ssh things like use Capistrano, vlad, create gems for rubyforge, etc. You can do these things using cygwin, but it's such a pain in the arse to use cygwin and windows working for everything.
2) The final straw was when trying to kick off background tasks in a rails app only to realize that windows can't fork processes.... didn't even bother with cygwin for this one, just switched to Ubuntu so I don't have to keep working around these issues.
Ubuntu 9.0.4 is pretty hot though, quite impressed so it may not be so bad.
I started life as a programmer in 1981 on early Unix systems. I stayed a pure Unix person through 1995. Then 'stuff' happened, (business ownership), and Windows came into my life.
So in 2007 I start learning RoR, pure Windows. I deployed on Joyent, which is Solaris. I've successfully developed two large apps, developed on Windows, and deployed on Solaris/Apache/Mongrel, without major incident.
The only Windows issue I ever remember is that I had to force filesystem reads and writes into binary mode to fix a 'development' vs. 'deployment' issue.
I honestly don't see any problem with developing on Windows and Deploying on Unix. But I had an extensive Unix background, I'm not sure the story would have been the same had I not know Unix.
Also, I'll only ever work on the RoR apps I build for my business. I'll never need to build any other RoR apps, I'll never develop any plugins, never have to take over another project, never have anyone INSIST I include something only available in something that doesn't work well with my Windows development environment, etc...
I'd say this:
If you are responsible for developing a Web app for your employer, and that employer is Windows based, that SHOULD NOT preclude you from considering RoR as platform. The app would have to be deployed by a third party, unless your employer is large enough and the project important enough to warrant in house Unix systems.
So if you know SQUAT about Unix, you MAY need a little help along the way. If you go with a third party Rails host, check out their support forums, make sure there are people willing and able to talk a non-Unix person through any deployment/setup and maintenance issues.
I'll give you an example, on Joyent, if I want to run a migration, I have to go through their Database GUI thingy, log into the database, then 'execute' a command. OK, so I get a simple text_field where I enter input destined for a Unix shell, which is:
cd /user/myhome/sites/mysite && rake db:migrate RAILS_ENV=production
That might not have been so easy to figure out had I not had the Unix background.