No voy a hacer esto en una discusión de Rails vs Framework X, ya hay muchas de esas. Después de considerar seriamente qué marco voy a utilizar para mi próxima implementación, decidí que es muy difícil dejar de lado la exposición de REST REST Rails te ofrece un trabajo mínimo. Esto es algo que requiere un poco más de trabajo en Django, y teniendo en cuenta que estoy poniendo mayor énfasis en la porción API de la aplicación, Rails tiene más sentido esta vez. Teniendo en cuenta lo importante que es para mí escribir una aplicación que contenga clientes heterogéneos (iphone/android/tabletas) a los que pueda acceder (no solo navegadores web), necesito poder crear API RESTful con la mínima resistencia desde cualquier marco que esté utilizando.¿Ruby 1.9.1 está realmente listo y es más rápido para una nueva implementación de Rails?
Mi pregunta es, ¿está listo Rails para manejar una aplicación de tamaño de Twitter, pero algo que hace aproximadamente 75,000 visitas únicas al día? ¿Ruby 1.9.1 realmente mejora las cosas? Hay muchas historias de pesadillas e igualmente historias de éxito dependiendo de a quién le preguntes. Joel Spolsky (uno de los fundadores de stackoverflow.com), believes Ruby itself is just not ready for prime time porque todavía es considerablemente más lento que otros lenguajes interpretados. No me preocupa llegar al tamaño de Twitter (es un problema que deseo tener algún día), pero por la misma razón, tengo un sitio con un promedio de 75,000 usuarios únicos por día. Me pregunto qué tipo de problemas de escalado me encontraré al decidir usar Ruby 1.9.1 + los últimos Rails (costos de CPU + huella de memoria) como parte de mi stack de API frente a solo tomarme el tiempo para realmente hacer un poco más trabajar en Django para construir una API RESTful. Como Joel menciona en su artículo, no quiero comprar 100 servidores cuando puedo comprar 10. Me encantaría estar convencido de por qué Rails ahora está listo para cumplir con mis requisitos.
Quizás también deba considerar Rubinius (http://rubini.us) /) Creo que el objetivo de Rubinius es una implementación de Ruby y más escalable. – adamse
Como nota al margen, Rails todavía estaba en su infancia en 2006 cuando Joel escribió ese artículo. En aquel entonces fcgi era el camino a seguir. Además, la mayoría de los problemas de twitters no se debían a que los rieles son lentos, sino que los rieles solo pueden acceder a una base de datos. Claro que usaron sql simple, pero cualquier capa de abstracción agrega sobrecarga independientemente del lenguaje utilizado. Cuando pones todo en perspectiva incluso si ruby 1.9.x es el doble de rápido, la velocidad general de la aplicación solo aumentará ligeramente. – vise
Además de Django, también hay web2py, en lo que respecta a los marcos basados en Python; el autor diseñó web2py para incluir características de django y conveniencias de rieles. –