Wow!! your comment encapsulates the thinking of every wannabe startup loser that ends up smoking crack on some beach in San Francisco"
Will making it faster increase the chances of more people using it? Also this attitude of building shit products (Yes software is a product) because..well the chances are it will fail.. is precisely why so many startups fail. This is why you get one crapola startup after another........
"Show HN: Crap.ly -- we built this in 3 weeks using Ruby, it will scale up to 20 users before craping out, its a twitter scraper that connects to app.net and diaspora showing how much Money your Kick-starter project has made and includes quotes from Paul Graham about how to build a successful startup, because he has built so many"
Imagine Linus had built Linux using fucking node.js
Imagine your shock when you build your craptastic app in C++ and wonder why it's not any faster than a scripted app. I'll give you a hint ahead of time: most bottlenecks aren't processing time, they're DB or IO limited.
Not strictly true. In the bigger companies, everyone knows that DBs (which is really just a special case of I/O) and I/O are slow (we tend not to hire them if they don't - one of my favoured systems & arch. interview questions[1] is on memory/storage hierarchies). The more interesting problem is what ELSE you've traded off to eliminate I/O on the common path - and in many languages it turns out to be memory fragmentation and/or garbage collection time. In Java, stop-the-world GC pauses of multiple seconds are not unheard of, and it's no fun being Oracle's test bed for undocumented GC features. It's also no fun when you find out you can't restart your multi-gigabyte heap JVM because the underlying OS has fragmented RAM so badly it can't alloc that heap in a single contiguous chunk.
This is something newbies repeat to justify their choice of a piss poor implementation. Sure with 10 users hitting your Rails app it might perform the same as Nginx with a custom C handler talking to a database written in C, but increase the load and soon your handing Amazon thousands a month on ec2 nodes while I am still on a small Linode. The funny thing is because of code gen and experience I can probably write my app faster than you dicking around with framework after framework
App speed matters some. But not nearly as much as a lot of other things. And when speed is the biggest problem, your users can tell you and the fixes are pretty straightforward.
The hard things to solve require a lot of user-facing iteration. Basically, the faster you can try new things, the more likely you'll get product-market fit before you run out of money.
My feelings on Rails are decidedly mixed, but fast prototyping is one of the things they got right.
