[facorreia]

Does this make sense? They don't mention trying to get support from Engine Yard on hosting their app on Rails without kernel panics, or trying a managed solution such as Heroku, or trying other OSs other than Ubuntu such as CentOS or something from Joyent. Just trying with the best possible syadmin they could hire and "Rails Core members".

Anyway, kudos for not submitting their users to a service they're not confident they would be able to provide with adequate quality and better luck next time!

[npsimons]

or trying other OSs other than Ubuntu such as CentOS or something from Joyent.

Or even just Debian. I ran into issues (years ago) with Ubuntu stability due to closed source drivers on a laptop; sure, I have the skills to debug that sort of thing, but why waste my time? I had been running Debian just fine on desktops and servers for years, and after switching the laptop to it, the lockups stopped.

I'm more than willing to admit there may be real technical issues they ran into, but it sounds to me like they gave up too easy, and we may never know what the problems are. Would've been nice to at least have seen a bug report (honestly don't know if they submitted any, but I'm willing to bet they didn't).

[beatgammit]

Or Arch Linux. Arch packages are pretty vanilla, so it would be a pretty good way to reduce the attack surface.

Also, with Arch, you get less by default, so you'll end up with a cleaner system. I didn't realize how much stuff I didn't need on a default install of Fedora until I set up an Arch system.

[cpeterso]

I'm curious what kind of "massive performance slowdowns" they encountered with Rails 3 that could "not be identified".

[cheald]

Me too, because it sounds an awful lot like someone doesn't know how to use ruby-prof.

[ahoyhere]

You realize that in your example, "somebody" would be several Rails Core team members, right?

It's easy to armchair quarterback… especially if you're not hampered by actually reading the very brief bit of content you're speculating about.

[cheald]

Yes, it's very easy to armchair quarterback. But I also have experience actually doing what I'm talking about - for example, I've contributed patches back to Haml and MongoMapper that have improved their respective speeds by ~25% and ~40% on average respectively. I've profiled and optimized multiple production apps to eliminate these kinds of issues, written tools to aid in memory profiling, tracked down and fixed memory leaks in various gems, and have yet to run into a mysterious "unsolvable and unexplainable" performance problem. If you can't explain it, that means you just don't know where to look.

Software is deterministic. If you can't explain why it's doing something, then it's not leprechauns fiddling with your bits - it's something that you just don't understand yet, and will have to dig a bit to find it. I'm not speaking from armchair quarterbacking here - I'm speaking from experience.

I am exceptionally dubious that you were encountering problems that were just not solvable, let alone explainable. Doing the handwavey "nobody can explain it" has a particuarly bad odor to it.

If you want to do a full writeup on the problems you encountered and what you tried to do to solve them and why you eventually gave up on them, I will be first in line to read it.

[ahoyhere]

I never said there were leprechauns, nor unsolvable. What I said was: Some of the absolute best & most knowledgeable people couldn't find them.

We did have 3-4 of the Rails Core team members investigating our Rails 3.x problems and none of them could figure out what it was. The problems were so terrible it made it impossible to develop with Rails 3.x any more. Obviously Rails Core members were both A) friends, and B) highly motivated for us to keep using Rails 3.x.

The problem with trusting your abilities is that you can't imagine a scenario where they will let you down. And yet, many such scenarios exist.

[cheald]

You obviously know more about this situation than I do, so I'm not going to be able to win any rational argument unless you choose to disclose more details.

I get your suggestion of hubris here, but again, I'm speaking from experience. I've done the solo technical founder thing, and that came with a whole host of problems that seemed unsolvable and which I didn't have anyone to appeal to for answers. Those are the problems that taught me most of what I know - most importantly that when you run into something that you don't understand, it's an opportunity to learn about it and solve it, rather than to just give up. In the Rails world, where the entire software stack is open-source down to the kernel it runs on, there is literally nothing to get in the way of understanding what's happening at any point of the application's execution.

I'll reiterate that if you want to do a writeup on why your circumstances were unique, and the problems you faced which were so crippling that they forced a rewrite, I'd love to read it. The suggestion that Rails 3 has landmines so critical in it that it necessitated a full product rewrite in Rails 2 is exceptionally weighty and should not be asserted without a very specific cataloging of what those problems are. That particular assertion - "Rails 3 has problems that cost us $XX,XXX and the Rails Core team doesn't have a clue what they are" - is a big one.