Elegir Java vs Python en Google App Engine

Actualmente, Google App Engine es compatible con Python y Java. El soporte de Java es menos maduro. Sin embargo, Java parece tener una lista más larga de bibliotecas y especialmente soporte para el código de bytes de Java, independientemente de los idiomas utilizados para escribir ese código. ¿Qué idioma dará un mejor rendimiento y más potencia? Por favor avise. ¡Gracias!

Editar: http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1

Editar: Por "poder" me refiero a una mejor capacidad de expansión e inclusión de las bibliotecas disponibles fuera del marco. Sin embargo, Python solo permite bibliotecas Python puras.

Soy parcial (siendo un experto en Python pero bastante oxidado en Java), pero creo que el tiempo de ejecución de Python de GAE es actualmente más avanzado y mejor desarrollado que el tiempo de ejecución de Java: el primero ha tenido un año adicional para desarrollarse y madurar, después de todo .

Por supuesto, es difícil predecir cómo avanzarán las cosas: la demanda es probablemente más fuerte en el lado de Java (especialmente porque no se trata solo de Java, sino también de otros lenguajes ubicados en la parte superior de la JVM, por lo que es LA manera de ejecutar, por ejemplo, PHP o código Ruby en App Engine); Sin embargo, el equipo de Python App Engine tiene la ventaja de tener a bordo a Guido van Rossum, el inventor de Python y un ingeniero increíblemente fuerte.

En términos de flexibilidad, el motor de Java, como ya se mencionó, ofrece la posibilidad de ejecutar el código de bytes JVM hecho por diferentes idiomas, no solo Java, si está en una tienda multilingüe, eso es bastante positivo. Viceversa, si detesta Javascript pero debe ejecutar algún código en el navegador del usuario, el GWT de Java (que genera el Javascript para usted a partir de su codificación de nivel Java) es mucho más rico y avanzado que las alternativas del lado de Python (en la práctica, si elige Python, usted mismo escribirá algo de JS para este propósito, mientras que si elige Java GWT es una alternativa útil si detesta escribir JS).

En términos de bibliotecas, es casi un lavado: la JVM está lo suficientemente restringida (sin hilos, sin cargadores de clases personalizados, sin JNI, sin base de datos relacional) para obstaculizar la reutilización simple de las bibliotecas Java existentes tanto o más que Python existente las bibliotecas están igualmente obstaculizadas por restricciones similares en el tiempo de ejecución de Python.

En términos de rendimiento, creo que es un lavado, aunque debe comparar sus propias tareas: no confíe en el rendimiento de las implementaciones JVM basadas en JIT altamente optimizadas que descuentan sus grandes tiempos de inicio y huellas de memoria, porque el motor de la aplicación el entorno es muy diferente (los costos de inicio se pagarán a menudo, ya que las instancias de su aplicación se inician, se detienen, se mueven a diferentes hosts, etc., todo de manera transparente para usted; tales eventos suelen ser mucho más baratos con entornos de tiempo de ejecución de Python que con JVM).

La situación XPath / XSLT (para ser eufemístico ...) no es exactamente perfecta en ninguno de los lados, suspiro, aunque creo que puede ser un poco menos malo en la JVM (donde, aparentemente, se puede hacer que corran grandes subconjuntos de Saxon) , con un poco de cuidado). Creo que vale la pena abrir problemas en la página de problemas de Appengine con XPath y XSLT en sus títulos; en este momento solo hay problemas para solicitar bibliotecas específicas, y eso es miope: realmente no me importa CÓMO se implementa un buen XPath / XSLT, para Python y / o Java, siempre que pueda usarlo. (Las bibliotecas específicas pueden facilitar la migración del código existente, ¡pero eso es menos importante que poder realizar tareas como "aplicar rápidamente la transformación XSLT" de ALGUNA forma!). Sé que destacaría este problema si estuviera bien redactado (especialmente en una forma independiente del idioma).

Por último, pero no menos importante: recuerde que puede tener una versión diferente de su aplicación (usando el mismo almacén de datos), algunas de las cuales se implementan con el tiempo de ejecución de Python, algunas con el tiempo de ejecución de Java y puede acceder a versiones que difieren de la "predeterminada / activa "uno con URL explícitas. Por lo tanto, puede hacer que tanto el código Python como Java (en diferentes versiones de su aplicación) usen y modifiquen el mismo almacén de datos, lo que le otorga aún más flexibilidad (aunque solo uno tendrá la URL "agradable" como foobar.appspot.com - lo cual probablemente sea importante solo para el acceso de los usuarios interactivos en los navegadores, me imagino ;-).

Mire esta aplicación para ver los cambios en el rendimiento de Python y Java:

http://gaejava.appspot.com/ (editar: disculpas, el enlace está roto ahora. Pero el siguiente párrafo todavía se aplicaba cuando lo vi ejecutándose por última vez)

Actualmente, Python y el uso de la API de bajo nivel en Java son más rápidos que JDO en Java, para esta simple prueba . Al menos si el motor subyacente cambia, esa aplicación debería reflejar los cambios de rendimiento.

Según la experiencia con la ejecución de estas máquinas virtuales en otras plataformas, diría que probablemente obtendrá más rendimiento bruto de Java que Python. Sin embargo, no subestime los puntos de venta de Python: el lenguaje Python es mucho más productivo en términos de líneas de código; el acuerdo general es que Python requiere un tercio del código de un programa Java equivalente, mientras se mantiene como o más legible. Este beneficio se multiplica por la capacidad de ejecutar código inmediatamente sin un paso de compilación explícito.

Con respecto a las bibliotecas disponibles, encontrará que gran parte de la extensa biblioteca de tiempo de ejecución de Python funciona de forma inmediata (al igual que Java). El popular marco web Django ( http://www.djangoproject.com/ ) también es compatible con AppEngine.

Con respecto al 'poder', es difícil saber a qué te refieres, pero Python se usa en muchos dominios diferentes, especialmente en la Web: YouTube está escrito en Python, al igual que Sourceforge (a partir de la semana pasada).

Junio ​​de 2013: este video es una muy buena respuesta de un ingeniero de Google:

http://www.youtube.com/watch?v=tLriM2krw2E

TLDR; es:

• Elija el idioma con el que usted y su equipo son más productivos
• Si desea construir algo para producción: Java o Python (no Go)
• Si tiene un gran equipo y una base de código compleja: Java (debido al análisis de código estático y la refactorización)
• Pequeños equipos que iteran rápidamente: Python (aunque Java también está bien)

Una pregunta importante a considerar al decidir entre Python y Java es cómo usará el almacén de datos en cada idioma (y la mayoría de los otros ángulos de la pregunta original ya se han cubierto bastante bien en este tema).

Para Java , el método estándar es usar JDO o JPA. Estos son excelentes para la portabilidad, pero no son muy adecuados para el almacén de datos.

Hay disponible una API de bajo nivel, pero este es un nivel demasiado bajo para el uso diario; es más adecuado para crear bibliotecas de terceros.

Para Python hay una API diseñada específicamente para proporcionar aplicaciones con acceso fácil pero potente al almacén de datos. Es genial, excepto que no es portátil, por lo que te encierra en GAE.

Afortunadamente, se están desarrollando soluciones para las debilidades enumeradas para ambos idiomas.

Para Java , la API de bajo nivel se está utilizando para desarrollar bibliotecas de persistencia que se adaptan mucho mejor al almacén de datos que JDO / JPA (IMO). Los ejemplos incluyen el proyecto Siena y Objectify .

Recientemente comencé a usar Objectify y considero que es muy fácil de usar y adecuado para el almacén de datos, y su creciente popularidad se ha traducido en un buen soporte. Por ejemplo, Objectify es oficialmente compatible con el nuevo servicio Cloud Endpoints de Google. Por otro lado, Objectify solo funciona con el almacén de datos, mientras que Siena está 'inspirada' en el almacén de datos, pero está diseñada para funcionar con una variedad de bases de datos SQL y almacenes de datos NoSQL.

Para Python , se están haciendo esfuerzos para permitir el uso de la API del almacén de datos GAE de Python fuera de GAE. Un ejemplo es el backend SQLite que Google lanzó para su uso con el SDK, pero dudo que tengan la intención de que esto crezca en algo listo para la producción. El proyecto TyphoonAE probablemente tenga más potencial, pero tampoco creo que esté listo para la producción (corríjame si me equivoco).

Si alguien tiene experiencia con alguna de estas alternativas o conoce otras, agréguelas en un comentario. Personalmente, me gusta mucho el almacén de datos de GAE, considero que es una mejora considerable con respecto al AWS SimpleDB, por lo que deseo el éxito de estos esfuerzos para aliviar algunos de los problemas al usarlo.

Recomiendo encarecidamente Java para GAE y he aquí por qué:

1. Rendimiento: Java es potencialmente más rápido que Python.
2. El desarrollo de Python está bajo la presión de la falta de bibliotecas de terceros. Por ejemplo, no hay XSLT para Python / GAE en absoluto. Casi todas las bibliotecas de Python son enlaces C (y GAE no las admite).
3. API de Memcache: Java SDK tiene capacidades más interesantes que Python SDK.
4. API del almacén de datos: JDO es muy lento, pero la API nativa del almacén de datos de Java es muy rápida y fácil.

Estoy usando Java / GAE en desarrollo en este momento.

Como ha identificado, el uso de una JVM no lo limita a usar el lenguaje Java. Puede encontrar una lista de idiomas y enlaces JVM aquí . Sin embargo , Google App Engine restringe el conjunto de clases que puede usar del conjunto Java SE normal, y querrá investigar si alguna de estas implementaciones se puede usar en el motor de la aplicación.

EDITAR: veo que has encontrado esa lista

No puedo comentar sobre el rendimiento de Python. Sin embargo, la JVM es una plataforma muy potente en cuanto al rendimiento, dada su capacidad de compilar y optimizar dinámicamente el código durante el tiempo de ejecución.

En última instancia, el rendimiento dependerá de lo que haga su aplicación y de cómo la codifique. En ausencia de más información, creo que no es posible dar más consejos en esta área.

Me ha sorprendido lo limpio, directo y sin problemas que es el SDK de Python / Django. Sin embargo, comencé a encontrarme con situaciones en las que necesitaba comenzar a hacer más JavaScript y pensé que podría aprovechar el GWT y otras utilidades de Java. Acabo de llegar a la mitad del tutorial de GAE Java, y he tenido un problema tras otro: problemas de configuración de Eclipse, versión de JRE, la complejidad de Java y un tutorial confuso y posiblemente roto. Echando un vistazo a este sitio y otros vinculados desde aquí me lo aseguró. Regresaré a Python y buscaré pijamas para ayudarme con mis desafíos de JavaScript.

Llego un poco tarde a la conversación, pero aquí están mis dos centavos. Realmente me fue difícil elegir entre Python y Java, ya que estoy bien versado en ambos idiomas. Como todos sabemos, hay ventajas y desventajas para ambos, y debe tener en cuenta sus requisitos y los marcos que funcionan mejor para su proyecto.

Como suelo hacer en este tipo de dilemas, busco números que respalden mi decisión. Decidí ir con Python por muchas razones, pero en mi caso, había un argumento que era el punto de inflexión. Si busca "Google App Engine" en GitHub a partir de septiembre de 2014 , encontrará la siguiente figura:

Podría haber muchos sesgos en estos números, pero en general, hay tres veces más repositorios GAE Python que repositorios GAE Java. No solo eso, sino que si enumera los proyectos por el "número de estrellas", verá que la mayoría de los proyectos de Python aparecen en la parte superior (debe tener en cuenta que Python ha existido por más tiempo). Para mí, este es un caso sólido para Python porque tomo en cuenta la adopción y el soporte de la comunidad, la documentación y la disponibilidad de proyectos de código abierto.

Es una buena pregunta, y creo que muchas de las respuestas han dado buenos puntos de vista de pros y contras en ambos lados de la cerca. He probado AppEngine basado en Python y JVM (en mi caso, estaba usando Gaelyk, que es un marco de aplicación Groovy creado para AppEngine). Cuando se trata del rendimiento en la plataforma, una cosa que no había considerado hasta que me estaba mirando a la cara es la implicación de "Solicitudes de carga" que ocurren en el lado Java de la cerca. Cuando se utiliza Groovy, estas solicitudes de carga son asesinas.

Puse una publicación sobre el tema ( http://distractable.net/coding/google-appengine-java-vs-python-performance-comparison/ ) y espero encontrar una manera de solucionar el problema, pero si no, creo que volveré a una combinación de Python + Django hasta que las solicitudes Java de arranque en frío tengan menos impacto.

Según cuánto escucho a la gente de Java quejarse de AppEngine en comparación con los usuarios de Python, diría que Python es mucho menos estresante de usar.

También está el proyecto Unladen Swallow , que aparentemente está financiado por Google si no es propiedad de Google. Están tratando de implementar un back-end basado en LLVM para Python 2.6.1 bytecode, para que puedan usar un JIT y varias optimizaciones de código nativo / GC / multi-core agradables. (Buena cita: "Aspiramos a no hacer un trabajo original, sino que utilizamos la mayor cantidad posible de los últimos 30 años de investigación"). Están buscando una aceleración 5x de CPython.

Por supuesto, esto no responde a su pregunta inmediata, sino que apunta hacia un "cierre de la brecha" (si corresponde) en el futuro (con suerte).

La belleza de python hoy en día es lo bien que se comunica con otros idiomas. Por ejemplo, puede tener python y java en la misma tabla con Jython. Por supuesto, jython, aunque es totalmente compatible con las bibliotecas de Java, no es totalmente compatible con las bibliotecas de Python. Pero es una solución ideal si desea meterse con las bibliotecas de Java. Incluso le permite mezclarlo con código Java sin codificación adicional.

Pero incluso Python en sí ha dado algunos pasos por alto. Vea ctypes, por ejemplo, cerca de la velocidad C, accesos directos a las bibliotecas C, todo esto sin dejar la comodidad de la codificación python. Cython va un paso más allá, permitiendo mezclar el código c con el código python con facilidad, o incluso si no desea meterse con c o c ++, aún puede codificar en python pero usar variables de tipo estático haciendo que sus programas python sean tan rápidos como las aplicaciones C . Por cierto, Google utiliza y admite Cython.

Ayer incluso encontré herramientas para python para alinear C o incluso ensamblar (ver CorePy), no puedes ser más poderoso que eso.

Python es seguramente un lenguaje muy maduro, no solo sobre sí mismo, sino que puede cooperar con cualquier otro idioma con facilidad. Creo que eso es lo que hace de Python una solución ideal incluso en escenarios muy avanzados y exigentes.

Con python puede tener acceso a C / C ++, Java, .NET y muchas otras bibliotecas con casi cero codificación adicional, lo que le brinda también un lenguaje que minimiza, simplifica y embellece la codificación. Es un lenguaje muy tentador.

Ido con Python a pesar de que GWT parece una combinación perfecta para el tipo de aplicación que estoy desarrollando. JPA está bastante desordenado en GAE (por ejemplo, no @Embeddable y otras limitaciones oscuras no documentadas). Después de pasar una semana, puedo decir que Java no se siente bien en GAE en este momento.

Hay que tener en cuenta los marcos que pretende utilizar. No todos los marcos en el lado de Java son adecuados para aplicaciones que se ejecutan en App Engine, que es algo diferente de los servidores de aplicaciones Java tradicionales.

Una cosa a considerar es el tiempo de inicio de la aplicación. Con las aplicaciones web Java tradicionales, realmente no necesita pensar en esto. La aplicación se inicia y luego se ejecuta. Realmente no importa si el inicio tarda 5 segundos o un par de minutos. Con App Engine, puede terminar en una situación en la que la aplicación solo se inicia cuando llega una solicitud. Esto significa que el usuario está esperando mientras su aplicación se inicia. Las nuevas funciones de GAE, como las instancias reservadas, ayudan aquí, pero verifique primero.

Otra cosa son las diferentes limitaciones de GAE psoes en Java. No todos los marcos están contentos con las limitaciones sobre qué clases puede usar o el hecho de que los hilos no están permitidos o que no puede acceder al sistema de archivos local. Estos problemas probablemente sean fáciles de descubrir simplemente buscando en Google la compatibilidad con GAE.

También he visto a algunas personas quejarse de problemas con el tamaño de la sesión en los marcos de interfaz de usuario modernos (Wicket, a saber). En general, estos marcos tienden a hacer ciertas compensaciones para hacer que el desarrollo sea divertido, rápido y fácil. En ocasiones, esto puede generar conflictos con las limitaciones de App Engine.

Inicialmente comencé a desarrollar trabajando en GAE con Java, pero luego cambié a Python por estas razones. Mi sensación personal es que Python es una mejor opción para el desarrollo de App Engine. Creo que Java está más "en casa", por ejemplo, en Elastic Beanstalk de Amazon.

PERO con App Engine las cosas están cambiando muy rápidamente. GAE está cambiando a sí mismo y a medida que se vuelve más popular, los marcos también están cambiando para evitar sus limitaciones.