java - features - google app engine launcher

Elegir Java vs Python en Google App Engine (15)

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 bytecode de Java, independientemente de los idiomas utilizados para escribir ese código. ¿Qué idioma dará 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 bibliotecas disponibles fuera del marco. Python solo permite bibliotecas puras de Python.

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

EDIT: veo que has encontrado una lista

No puedo comentar sobre el rendimiento de Python. Sin embargo, la JVM es una plataforma muy poderosa en términos de rendimiento, dada su capacidad para compilar y optimizar código dinámicamente 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. A falta de más información, creo que no es posible dar más consejos sobre este tema.

En función de la experiencia con la ejecución de estas máquinas virtuales en otras plataformas, diría que probablemente obtendrás un rendimiento más crudo 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 permanece igual 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, descubrirá que gran parte de la extensa biblioteca de tiempo de ejecución de Python funciona de forma predeterminada (al igual que Java). El popular marco web de Django ( http://www.djangoproject.com/ ) también es compatible con App Engine.

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).

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 valla. Gaelyk con AppEngine basado en Python y JVM (en mi caso estaba usando Gaelyk que es un framework de aplicaciones Groovy creado para AppEngine). Cuando se trata de rendimiento en la plataforma, una cosa que no había considerado hasta que me miraba a la cara es la implicación de "Solicitudes de carga" que ocurren en el lado Java de la valla. Al usar Groovy estas solicitudes de carga son un asesino.

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

La belleza de Python ahora es qué tan bien se comunica con otros idiomas. Por ejemplo, puedes tener python y java en la misma tabla con Jython. Por supuesto, jython a pesar de que es totalmente compatible con las bibliotecas de Java, no es compatible con bibliotecas de Python completas. Pero es una solución ideal si quiere meterse con las bibliotecas de Java. Incluso te permite mezclarlo con código Java sin codificación adicional.

Pero incluso Python mismo ha hecho algunos pasos forwared. Ver ctypes, por ejemplo, cerca de la velocidad C, accees directos a bibliotecas C todo esto sin dejar la comodidad de la codificación python. Cython va un paso más allá, permitiendo mezclar código c con código python con facilidad, o incluso si no quiere meterse con c o c ++, aún puede codificar en python pero usar variables de tipo estáticas haciendo que sus programas python sean tan rápidos como C . Por cierto, Cython es usado y respaldado por Google.

Ayer incluso encontré herramientas para Python para alinear C o incluso Assembly (ver CorePy), no se puede obtener nada más poderoso que eso.

Python es sin duda un lenguaje muy maduro, no solo para mantenerse sobre sí mismo, sino también para cooperar con cualquier otro idioma con facilidad. Creo que eso es lo que hace que python sea 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 que le proporciona también un lenguaje que minimiza, simplifica y embellece la codificación. Es un lenguaje muy tentador.

Llego un poco tarde a la conversación, pero aquí están mis dos centavos. Realmente tuve dificultades para elegir entre Python y Java, ya que estoy bien versado en ambos idiomas. Como todos sabemos, existen ventajas y desventajas para ambos, y debe tener en cuenta sus requisitos y los marcos que funcionen 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, hubo una trama que fue el punto de inflexión. Si busca "Google App Engine" en GitHub a partir de septiembre de 2014 , encontrará la siguiente figura:

Puede 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 enlistas los proyectos por el "número de estrellas" verás que la mayoría de los proyectos de Python aparecen en la parte superior (debes tener en cuenta que Python lleva más tiempo en el mercado). Para mí, esto es un buen argumento para Python porque tengo en cuenta la adopción y soporte de la comunidad, la documentación y la disponibilidad de proyectos de código abierto.

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

http://gaejava.appspot.com/ (edit: disculpas, el enlace está roto ahora. Pero el siguiente párrafo todavía se aplicó cuando vi que se ejecutaba 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 debe reflejar los cambios de rendimiento.

Recomiendo encarecidamente Java para GAE y este es el motivo:

Rendimiento: Java es potencialmente más rápido que Python.
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 Python son enlaces C (y GAE no las soporta).
Memcache API: Java SDK tiene capacidades más interesantes que Python SDK.
API Datastore: 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.

Se fue con Python aunque 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 no documentadas oscuras). Después de haber pasado una semana, puedo decir que Java no se siente bien en GAE en este momento.

Según lo mucho que escucho que las personas de Java se quejan de AppEngine en comparación con los usuarios de Python, yo diría que Python es mucho menos estresante de usar.

Soy parcial (soy 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 más para desarrollarse y madurar, después de todo .

La forma en que las cosas seguirán adelante es, por supuesto, difícil de predecir; 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 encima de la JVM). o código de 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 Java, como ya se mencionó, ofrece la posibilidad de ejecutar bytecode JVM hecho por diferentes idiomas, no solo Java, si estás en una tienda multilingüe que es un gran positivo. Viceversa, si detestas el Javascript pero debes ejecutar algún código en el navegador del usuario, Java''s GWT (generando el Javascript para ti a partir de tu código de Java) es mucho más rico y avanzado que las alternativas de Python (en la práctica, si eliges Python, usted mismo estará escribiendo algunos 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 es lo suficientemente restringida (sin hilos, sin cargadores de clases personalizadas, sin JNI, sin DB relacional) para dificultar la simple reutilización de bibliotecas Java existentes tanto, o más, que las existentes de Python. las bibliotecas se ven igualmente obstaculizadas por las 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 implementaciones JVM basadas en JIT altamente optimizadas, descontando 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, detienen, mueven a diferentes hosts, etc., todo trasparentemente a usted; dichos eventos suelen ser mucho más económicos con los entornos de tiempo de ejecución de Python que con las JVM).

La situación de 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, subconjuntos sustanciales de Saxon pueden ejecutarse , con algo de cuidado). Creo que vale la pena abrir los problemas en la página Appengine Issues con XPath y XSLT en sus títulos. En este momento solo hay problemas para pedir bibliotecas específicas, y eso es miope: realmente no me importa CÓMO se implementa un buen XPath / XSLT, para Python y / o para 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 manera! -). Sé que protagonizaría un tema así si está bien redactado (especialmente de una manera independiente del lenguaje).

Por último, pero no menos importante: recuerde que puede tener una versión diferente de su aplicación (utilizando el mismo almacén de datos), algunas de las cuales se implementan con el tiempo de ejecución de Python, otras con el tiempo de ejecución de Java y puede acceder a versiones que difieren del "predeterminado / activo "uno con URL explícitas". Por lo tanto, podría tener el código Python y Java (en diferentes versiones de su aplicación) usar y modificar el mismo almacén de datos, otorgándole aún más flexibilidad (aunque solo uno tendrá la URL "buena" como foobar.appspot.com - que probablemente sea importante solo para el acceso de los usuarios interactivos en los navegadores, imagino ;-).

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 backend basado en LLVM para bytecode de Python 2.6.1, para que puedan usar un JIT y varias optimizaciones nativas de código nativo / GC / multi-core. (Buena cita: "Aspiramos a no hacer ningún trabajo original, en lugar de utilizar la mayor parte de los últimos 30 años de investigación como sea posible"). Están buscando una velocidad 5 veces superior a CPython.

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

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 a las aplicaciones un acceso fácil pero poderoso al almacén de datos. Es genial, excepto que no es portátil, así que te encierra en GAE.

Afortunadamente, se están desarrollando soluciones para las debilidades enumeradas en 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 a JDO / JPA (IMO). Los ejemplos incluyen el proyecto de Siena y Objectify .

Recientemente comencé a usar Objectify y encuentro 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á ''inspirado'' por el almacén de datos, pero está diseñado para trabajar con una gran variedad de bases de datos SQL y datastores NoSQL.

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

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

Uno piensa en tener en cuenta los marcos que pretendes usar. No todos los marcos en el lado de Java son adecuados para las 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 tradicionales de Java, realmente no necesita pensar en esto. La aplicación se inicia y luego simplemente se ejecuta. Realmente no importa si la puesta en marcha lleva 5 segundos o un par de minutos. Con App Engine, es posible que termines en una situación en la que la aplicación solo se inicia cuando se recibe una solicitud. Esto significa que el usuario está esperando mientras se inicia la aplicación. Las nuevas funciones GAE como las instancias reservadas ayudan aquí, pero primero verifica.

Otra cosa son las diferentes limitaciones GAE psoes en Java. No todos los frameworks están contentos con las limitaciones sobre qué clases puedes usar o el hecho de que los threads no están permitidos o que no puedes acceder al sistema de archivos local. Probablemente, estos problemas sean fáciles de encontrar simplemente buscando en Google la compatibilidad GAE.

También he visto a algunas personas quejarse de problemas con el tamaño de la sesión en los marcos modernos de interfaz de usuario (Wicket, en concreto). En general, estos marcos tienden a hacer ciertas concesiones 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 el trabajo en GAE con Java, pero luego cambié a Python por estos motivos. 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 se está cambiando a sí mismo y, a medida que se vuelve más popular, los marcos también cambian para evitar sus limitaciones.

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 sean más productivos
Si quieres 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)

Me sorprendió lo limpio, directo y libre de problemas que es el SDK de Python / Django. Sin embargo, comencé a toparme con situaciones en las que necesitaba comenzar a hacer más JavaScript y pensé que podría querer aprovechar el GWT y otras utilidades de Java. Llegué justo a la mitad del tutorial de GAE Java y tuve un problema tras otro: problemas de configuración de Eclipse, versiones de JRE, la compleja complejidad de Java y un tutorial confuso y posiblemente roto. Revisando este sitio y otros vinculados desde aquí me lo aseguró. Regresaré a Python y analizaré Pajamas para ayudar con mis desafíos de JavaScript.