I've been an entrepreneur a long time and my take is:
1. Not a myth! Apple, Microsoft, Yahoo, Google, Facebook, Foursquare, ... There are counterexamples but certainly plenty of young ones. I'm 40+ now so no bias. :-)
2. Correct, myth. I could teach you to be an entrepreneur if you wanted to be one.
3. Myth
4. Myth. Gilt Groupe a good example.
5. Myth
Seems to me comparison to C++ might be more interesting. Wonder how that would be given there are 'growable arrays' and such. There's better (not perfect) safety given scoped_ptr, string classes, etc.
development agility is a goal of the project too, in addition to scale-out. i've seen a lot of happy users with a single server (or two) and that's all they need.
We've always clearly said don't build a bond trading system with it. Our philosophy is one-size-fits-all is over; use the right tool for the right problem.
Based on how I like to define the term, there is nothing in the NoSQL space that does full "ACID", including complex transactional semantics involving many objects, on many server clusters. That is ok : the perf + scale problem isn't really solvable if you don't give on something.
Clustered durability. You can request, per-write, "don't return until this data has been persisted to N other servers," with N chosen per-write.
So if you're running master/slave and choose N to be 1, you're durable (at the two server level). Run 5-replica sets and choose N to be 3 or 4, and you're basically guaranteed durability. One of your nodes goes down hard and bad things happen? You have four additional clones of it sitting and waiting to be copied.
This is actually more durable in cases of extreme hardware failure like, say, your RAID controller going out. However, it requires that you spend more on hardware. So do several other things Mongo does, like using a lot of RAM and disk to get faster writes, so that's in keeping with a lot of their other design decisions.
It's not perfect for every project, but it's a great choice for most of the same projects where you'd use Mongo in the first place.
Perhaps a better solution is to make trains more cell-based. (Think ATM.)
Each "car" holds just 2-4 people. they run on the tracks and switch on and off at the right stops. Very granular.
But still like a train in that you have tracks and power from the tracks. There is no conductor then, so everything would have to be computer controlled.
I've thought of that as well, but you've got serious problems with air resistance (and associated vibration) at high speeds unless you've got contoured fronts and backs. So you'd have to drop and add cars in the middle of the train... added complexity and you'd need every unit to be powered independently (true, many are, but this would be a requirement).
So picture parallel tracks with a merge-point somewhere ahead (or a few, in case one doesn't work). You've gotta split the train, merge in the new car, and merge it all back together, at moderately high speeds. Not much of a fun engineering challenge, methinks. The top-car probably makes more sense in this case. At low speeds, where all cars can be the same shape, certainly. Just remove / add to the front / end as needed.
Real world engineering issues aside, my gut feeling was that a suspended/hanging pod would offer more stability and ability to accelerate than a traditional pod resting on top of tracks. If the pod could swing back and forth, acceleration and deceleration would push riders down into their seats rather than back or forward toward the windshield.
The Big Bad Wolf and Batman roller coasters come to mind. :)
