[neya]

This is why I insist people to work on a robust stack from ground up, so it will be less painful in the long run. This is not to say that you shouldn't build a prototype in Rails to get everything up and running as quickly as possible and worry about scaling later, but, it is just my opinion that if you invest the time and effort in working with a robust stack (for example Scala+Lift), your investment will pay you off in the long run.

I've always admired rails for its flexibility and its enormous productivity boost, but all my serious applications are coded in Lift. I for one believe in "develop and forget", because I'd like to call myself a business guy than a programmer, though I'm deep into both. I like to spend more time expanding/marketing my business than worry about scaling it. But that's just my perspective.

JVM is terribly under-estimated and I realized this when I got started with Lift+Scala. Scala is a very powerful language and requires a totally different mindset (=functional). And Lift is fairly complex for those wishing to get started with it and has poor documentation, despite being a 5-year old Framework. But once you understand it fully (somehow), there's no looking back. Lift provides so many things out of the box, especially related to security (unlike PLay!), so it's kind of a trade-off you have to choose between. Even if you compare all the benchmarks, most of the JVM-based languages like Scala outperform even something like GO! (Ok, that's not fair, since GO is fairly new)

If you're interested in Scala, Coursera has a course on it by the creator of Scala himself (Martin Odersky).

[mnutt]

> I like to spend more time expanding/marketing my business than worry about scaling it.

If you're truly more interested in the business side, why don't you build it as quickly as possible in rails/django and then later if it warrants it you can hire some people to build it in lift/something else?

[neya]

Very good point. Truth is, I want to keep down the hiring as minimum as possible, particularly when I plan to bootstrap. Imagine, I could eliminate hiring these people just to 'scale my app' because I chose a language/framework that doesn't scale well. There's some savings in this process. I could be wrong though, because I'm only speculating and I've never hit that traffic level, and probably never will.

[redguava]

The point where you are having scaling issues because of the language then you are really going to be past the worrying about bootstrapping/hiring stage.

It sounds like you are spending time/effort worrying about scaling way before needed. If you can solve your problems you have today faster then I would do that, not hinder yourself today for possible problems way down the track.

[neya]

Very valid point there dude. I don't know dude...maybe I just want things to be efficient right from ground up...Or it could be the after-effects of falling in love with Functional programming in Scala :)

[redguava]

There is plenty of merit using a language you enjoy.

A certain language might be twice as fast to get work done in, but you can be 10 times as fast if you are enjoying yourself and motivated.

I just wouldn't kid yourself that scaling is the reason for the choice. Just enjoying it is plenty of reason.

[stock_toaster]

In addition, startups tend to pivot a few times, and agility is arguably more important early on than raw performance (depending on product of course).

[neya]

Agreed. But, probably my situation applies when you've come past all the pivoting and you've settled with one idea you decidedly are going to work on.

[davidw]

Pivoting stops when you have found a scalable, repeatable business model, not an idea to work on.