On Fri, Nov 10, 2006 at 08:50:12PM +0900, Leslie V. wrote:
} I have the deciding vote in a new (rather large) web app we need to
} develop. I am experienced in Rails, but the other 2 guys on the team
} know only C# and very basic Ruby. About 25% of the app could benefit
} from existing classes written in C#.
} So I could force everyone to learn ROR, which they may or may not
} thank me for, or I could learn ASP.NET. I know C# well but have never
} used ASP.NET.
} I doubt execution speed would be a factor, since the bottleneck will
} be in the database and there would be very few concurrent users. We’d
} make a lot of use of Ajax.
} So is there any advice? Anything I should take into account? Has
} anyone done large projects in both environments?
I have worked on large projects in both. As a language, I enjoy Ruby
than C# by a significant but not huge margin. As a framework, I enjoy
more than ASP.NET by a large margin. C# and ASP.NET make it slightly
to have many engineers working concurrently, but not by a whole lot.
it really gets interesting is in deployment. I am going to paint this in
rough brushstrokes, and make some generalizations, but I hope the
high-level view will be of use in making your decision. I’m also going
use numbers without units, which are really only useful for relative
comparisons since they mostly represent a vague performance metric
something to do with incoming requests based on my experience.
A single box running IIS/ASP.NET can probably manage at least 20-30.
than that and you need more boxes and a load balancer, plus you need to
make sure that all of your shared state is in the DB (or another
shared resource) rather than ASP.NET’s various implicitly shared
(e.g. class variables). You also have to figure out how to make sessions
explicitly shared resource (it might be easy, but it’s been a while and
don’t remember). It scales roughly linearly that way for a while,
to 500 or so, then gets much as when the shared resources become a
A single box running a single Rails process (whether lighttpd or
can manage maybe 5-15, depending on the demands of serving particular
requests. Beyond that you need at least multiple Rails processes and a
balancer, with session data stored somewhere other than in-process
(memcached is a good choice). A decently powerful box with plenty of
should be able to manage enough Rails processes to support maybe 40-60.
After that, it scales roughly linearly as you add boxes and processors,
to maybe 1000-1200. From there it gets significantly messier because you
need to deal with multiple levels of caching granularity, plus the same
concerns about shared resources as ASP.NET.
It sounds like your intended application will work well under either,
your small team and expected deployment size. The main
tradeoffs I see for your app are the existing code and that while Atlas
makes AJAX stuff easier with ASP.NET if you have anything trickier than
what Atlas supports you will find it more difficult to deal with in
that you would in Ruby.