I’ve heard some mentions of RubyMine on the Bike Shed and I’ve just joined a company that, bizarrely enough, the entire dev team uses RubyMine. Most of the devs come from a Cold Fusion background and I suppose RubyMine makes them feel more secure about. their Ruby and Rails code.
I personally have a strong snobbery against RubyMine because I feel that it’s exactly the kind of Eclipse-type tool favored by non-Rubyists. Also, folks I respect, like Thoughtbotters, Hashrocketeers, Pivots and others are generally Vim enthusiasts. I feel like I’m being promiscuous when I open Sublime 2 – RubyMine would feel like straight up prostitution.
So here are my questions for the community (hopefully some of the Thoughtbot crew can weigh in as well.)
Is anyone at Thoughtbot using RubyMine as their primary editor? What’s the prevailing attitude?
Why Vim? What’s the argument you’d give a coworker when you’re opening up Vim and they’re looking at you like you’ve grown a third arm. Actually more accurately, why not RubyMine? What makes my preferred Vim/Tmux setup preferable to RubyMine?
What about for doing things like Ember/js_framework_of_the_week? What is the editor to use for Haskell? Would it still be Vim? How about for Scala, C++, C… are IDEs required, suggested for those types of languages? What is the use case for Xcode vs. some other IDE? Swift and Obj c seem perfect for Xcode, but how does it fit into the overall dev toolkit? For example, you’re a Rails developer who wants to write C extensions or Rust extensions and perhaps a service in Haskell and then some iOS or Mac OS in Swift. You also dip into JS frameworks here and there. What’s the recommended setup for that?
I think when it comes down to it any editor will work. Vim just happens to feel more productive and have the ability to do nearly anything you want to in an editor. Rubymine is good though, but it comes down to personal preference. I would give Rubymine a shot if you still think you are faster or able to reliable code better in Vim then make the argument. I know pivtol labs requires everyone to use Rubymine. Not sure what their reasoning is behind that but I’m sure there is a business reason or technical reason driving that. In the end no company has ever said “The product failed and its all because we didn’t use Vim”.
I think almost every developer uses Vim. Some designers as well, but there’s more variability there.
We like it because we feel more efficient in it than any other editor. People here are pretty pragmatic, if something were better, I suspect it would start to be adopted aggressively.
@benorenstein it’s strange how Pivotal was a Vim shop and now apparently they’re using RubyMine. I wonder if JetBrains paid them to do that. In any case, I’m glad it’s still a Vim world – at least in this neighborhood. I’ll invest more time in getting Vim awesome. Thanks.
I’ve been a Vim user for about a year now after decades of vehemently opposing it. I still wouldn’t recommend it to anyone who isn’t willing to invest heavily into it, and when pairing with someone I quickly volunteer to switch to their editor of preference.
Vim has a steep learning curve, though not nearly as steep as it looks, and the payoff is well worth it. Within three weeks of full-time use I was as efficient as I had been Sublime.
I use Vim because it makes me a better developer. It make me a better developer because, with training, it’s easier and faster to navigate and edit text files. If you are unwilling to do the training, or don’t spend enough time editing text files to make the trade-off worthwhile, then I would not recommend Vim. If you live in text files and will for the next few years at least, then Vim is well worth it.
Vim, Emacs, Atom, RubyMine, or … they are all great editors. It’s just a personal preference and times that we invest on them to gain master to increase productivity. I have been using Vim for a couple years now, I’m happy with it, but I still learn all the times. Because I use terminal vim + tmux, so it can help me a lot from leaving terminal that could cause context switching between applications.