[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.

[ahoyhere]

If you'd like to prove your "experience" -- an exceptionally weighty assertion, given I don't know you from Adam, and you know nothing about my product -- I'd be happy to read that writeup.