Elegir Java vs Python en Google App Engine

StackOverflow https://stackoverflow.com/questions/1085898

Pregunta

Actualmente, Google App Engine es compatible con Python y Java.El soporte de Java está 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 lenguajes 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.Sin embargo, Python sólo permite bibliotecas puras de Python.

¿Fue útil?

Solución

Soy parcial (por ser un experto en Python pero bastante oxidado en Java) pero creo que el tiempo de ejecución Python de GAE es actualmente más avanzada y mejor desarrollado que el tiempo de ejecución de Java - la primera ha tenido un año adicional a desarrollarse y madurar , después de todo.

Como las cosas van a proceder en el futuro es, por supuesto, difícil de predecir - la demanda es probablemente más fuerte en el lado de Java (sobre todo porque no se trata sólo de Java, pero otros idiomas situado en lo alto de la JVM también, así que es la manera de por ejemplo, ejecutar código PHP o Ruby on App Engine); el equipo de App Engine Python sin embargo tiene la ventaja de tener a bordo de Guido van Rossum, el inventor de Python y un ingeniero increíblemente fuerte.

En cuanto a la flexibilidad, el motor de Java, como ya se ha mencionado, es que ofrece la posibilidad de ejecutar código de bytes JVM hecha por diferentes idiomas, no sólo en Java - si usted está en una tienda multi-idioma que es un bastante grande positivo. Viceversa, si detestan Javascript pero debe ejecutar algún código en el navegador del usuario, de Java GWT (generando el Javascript para usted de su codificación a nivel de Java) es mucho más rico y más avanzada que las alternativas del lado de Python (en la práctica, si lo desea Python, que estará escribiendo algunos JS para este propósito, mientras que si elige Java GWT es una alternativa útil si loathe escribir JS).

En cuanto a las bibliotecas es más o menos un lavado - la JVM está restringido suficiente (no hay hilos, no hay cargadores de clases personalizadas, sin JNI, sin relacional DB) que obstaculizan la sencilla reutilización de bibliotecas Java existentes tanto, o más, de bibliotecas de Python existentes se ven obstaculizados de manera similar por las restricciones similares sobre el tiempo de ejecución de Python.

En términos de rendimiento, creo que es un lavado, aunque debe de referencia en las tareas de su propio - no se basan en el rendimiento de las implementaciones de JVM basado en JIT altamente optimizados descontando sus grandes tiempos de arranque y capacidad de memoria, porque el medio ambiente motor de aplicación es muy diferente (costos iniciales se pagarán a menudo, ya se han iniciado las instancias de la aplicación, se detuvo, se trasladaron a diferentes hosts, etc, todo trasparently a usted - este tipo de eventos son típicamente mucho más barato con entornos de ejecución de Python que con JVM).

La situación XPath / XSLT (que es un eufemismo ...) no es exactamente perfecto en cada lado, suspiro, aunque creo que puede ser un poco menos malo en la JVM (donde, al parecer, subconjuntos sustanciales de Saxon pueden ser hecha para funcionar, con cierto cuidado). Creo que es un valor de temas de apertura en la página de problemas AppEngine con XPath y XSLT en su - títulos en este momento sólo hay cuestiones que piden bibliotecas específicas, y eso es miope: realmente no importa cómo se implementa un buen XPath / XSLT, para Python y / o para Java, siempre y cuando la usamos. (Bibliotecas específicas pueden facilitar la migración de código existente, pero eso es menos importante que ser capaz de realizar tareas tales como "aplicar rápidamente transformación XSLT" de alguna manera! -). Sé que había una estrella un tema tan si así lo expresó (sobre todo de una manera independiente del lenguaje).

Por último, pero no menos importante: recuerde que usted puede tener diferentes versiones de su aplicación (utilizando el mismo almacén de datos) algunos de los cuales se apliquen con el tiempo de ejecución de Python, algunos con el tiempo de ejecución de Java, y se puede acceder a las versiones que difieren de la " default / activa" con una URL explícitas. Por lo que podría tener tanto Python y código Java (en diferentes versiones de su aplicación) usar y modificar el mismo almacén de datos, la concesión de una flexibilidad aún mayor (aunque sólo uno tendrá el "buen" enlace como foobar.appspot.com - que es probablemente importante sólo para el acceso de los usuarios interactivos en los navegadores, me imagino; -).

Otros consejos

Mira esta aplicación para cambios en el rendimiento de Python y Java:

http://gaejava.appspot.com/ (De edición: disculpas, vínculo se rompe ahora Sin embargo, después del párrafo siendo aplicadas cuando lo vi corriendo pasado.)

Actualmente, Python y el uso de la API de bajo nivel en Java son más rápidos que JDO en Java, de esta sencilla prueba . Por lo menos si los cambios de motor subyacentes, esa aplicación debe reflejar los cambios de rendimiento.

Con base en la experiencia con el funcionamiento de estas máquinas virtuales en otras plataformas, yo diría que probablemente obtendrá más rendimiento bruto de Java que Python. No hay que subestimar los puntos de venta de Python, sin embargo: El lenguaje Python es mucho más productivo en términos de líneas de código - el acuerdo general es que Python requiere una tercera parte del código de un programa Java equivalente, sin dejar de ser tan o más legible. Este beneficio se multiplica por la posibilidad de ejecutar código inmediatamente sin una etapa de compilación explícita.

En cuanto a las bibliotecas disponibles, se dará cuenta de que gran parte de la extensa biblioteca de tiempo de ejecución Python funciona fuera de la caja (al igual que Java). El marco populares Web Django ( http://www.djangoproject.com/ ) también está soportado en App Engine.

En cuanto a la 'potencia', es difícil saber a qué se refiere, pero Python se utiliza en muchos campos diferentes, en especial la Web: YouTube está escrito en Python, como es Sourceforge (a partir de la semana pasada)

Junio ​​del 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 desea construir algo para producción:Java o Python (no Go)
  • Si tienes un equipo grande y una base de código compleja:Java (debido al análisis y refactorización del código estático)
  • Equipos pequeños que iteran rápidamente:Python (aunque Java también está bien)

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

Para Java , el método estándar es utilizar JDO o JPA. Éstos son grandes para la portabilidad, pero no son muy adecuadas para el almacén de datos.

Una API de bajo nivel está disponible, pero esto es demasiado bajo nivel para el uso del día a día - que es más adecuado para la construcción de bibliotecas 3 ª parte

.

En Python hay una API diseñada específicamente para proporcionar aplicaciones con acceso fácil pero de gran alcance para el almacén de datos. Es genial, excepto que no es portátil, por lo que se encaje en su GAE.

Afortunadamente, hay soluciones que están siendo desarrollados por las debilidades que figuran para los dos idiomas.

Para Java , la API de bajo nivel se utiliza para desarrollar bibliotecas de persistencia que son mucho más adecuado para el almacén de datos a continuación, JDO / JPA (OMI). Los ejemplos incluyen el href="https://github.com/siena/siena" rel="nofollow noreferrer"> Siena proyecto objetivar .

Recientemente he empezado a utilizar Objectify y estoy encontrando que es muy fácil de usar y muy adecuado para el almacén de datos, y su creciente popularidad se ha traducido en un buen apoyo. Por ejemplo, Objectify está soportado oficialmente por el nuevo servicio de Cloud Endpoints de Google. Por otro lado, Objectify sólo 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 variedad de ambas bases de datos SQL y almacenes de datos NoSQL.

En Python , hay esfuerzos que se realizan para permitir el uso de la API del almacén de datos Python GAE fuera de la GAE. Un ejemplo es el backend SQLite que Google liberado para su uso con el SDK, pero dudo que pretenden que esto crezca en producción algo listo. El proyecto TyphoonAE probablemente tiene más potencial, pero no creo que es la producción listo todavía o bien (corríjanme si me equivoco).

Si alguien tiene experiencia con cualquiera de estas alternativas, o sabe de otros, por favor añadirlos en un comentario. En lo personal, me gusta mucho el almacén de datos GAE - Me parece que es una mejora considerable sobre la AWS SimpleDB - por lo que deseo para el éxito de estos esfuerzos para aliviar algunos de los problemas en su uso

.

Lo estoy recomendando fuertemente 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 aquellos no están respaldadas por GAE).
  3. API de Memcache: Java SDK tienen habilidades más interesantes que SDK Python
    4. .
  4. API de almacén de datos:. JDO es muy lento, pero nativo Java API del almacén de datos es muy rápida y fácil

Estoy usando Java / GAE en el desarrollo en este momento.

A medida que haya identificado, utilizando una JVM no se restringe al uso del lenguaje Java. Una lista de los idiomas JVM y enlaces se puede encontrar aquí . No obstante , el Google App Engine restringe el conjunto de clases que se pueden utilizar a partir del conjunto normal de Java SE, y usted tendrá que investigar si alguna de estas implementaciones se puede utilizar en el motor de aplicación.

Edit: Veo que has encontrado una lista de este tipo

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

En última instancia el rendimiento dependerá de lo que hace su aplicación, y cómo se codificarlo. A falta de más información, yo creo que no es posible dar más punteros en este campo.

Me he quedado sorprendido por lo limpio, sencillo, y sin problemas el / Django SDK Python es. Sin embargo empecé a correr en situaciones en las que necesitaba para empezar a hacer más de JavaScript y pensé que podría querer tomar ventaja de la GWT y otras utilidades de Java. He llegado a mitad de camino a través del tutorial GAE Java, y he tenido un problema tras otro: Eclipse problemas de configuración, versionitis JRE, la complejidad de adormecer la mente de Java, y un tutorial confuso y posiblemente roto. El registro de salida este sitio y otros vinculados de aquí aseguró la victoria para mí. Voy a volver a Python, y voy a mirar en pijamas para ayudar con mis problemas de JavaScript.

Soy un poco tarde a la conversación, pero aquí están mis dos centavos. Realmente tenía un tiempo difícil elegir entre Python y Java, ya que yo soy muy versado en ambos idiomas. Como todos sabemos, hay ventajas y desventajas para ambos, y usted tiene que tomar en cuenta sus necesidades y los marcos que funcionan mejor para su proyecto.

A medida que suele hacer en este tipo de dilemas, busco números para apoyar mi decisión. Decidí ir con Python por muchas razones, pero en mi caso, había una trama que fue el punto de inflexión. Si se busca "Google App Engine" en GitHub como de Septiembre de 2014 , se encuentra la siguiente figura:

GAE idioma estadísticas

Puede haber varias sesgos en estos números, pero en general, hay tres veces más repositorios GAE Python que repositorios GAE Java. No sólo eso, sino que si la lista de los proyectos por el "número de estrellas", se verá que la mayoría de los proyectos de Python aparece en la parte superior (hay que tener en cuenta que Python ha sido por más tiempo). Para mí, esto hace un caso fuerte para Python porque tomo en cuenta la adopción de la comunidad y apoyo, documentación, y la disponibilidad de proyectos de código abierto.

Es una buena pregunta y creo que muchas de las respuestas han brindado buenos puntos de vista sobre los pros y los contras en ambos lados de la valla.Probé AppEngine basado en Python y JVM (en mi caso estaba usando Gaëlyk que es un marco de aplicación Groovy creado para AppEngine).Cuando se trata de rendimiento en la plataforma, una cosa que no había considerado hasta que me encontré frente a frente es la implicación de las "Solicitudes de carga" que ocurren en el lado de Java de la valla.Cuando se utiliza Groovy, estas solicitudes de carga son mortales.

Hice una publicación sobre el tema (http://ditractable.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 de inicio en frío de Java tengan menos impacto.

Sobre la base de lo mucho que escucho a la gente de Java se quejan de AppEngine en comparación con los usuarios de Python, diría Python es mucho menos estresante para su uso.

También hay proyectar trago des , que aparentemente es Google- financiado si no es propiedad de Google. Están tratando de implementar un entorno basado en LLVM para Python 2.6.1 código de bytes, para que puedan utilizar un JIT y varias optimizaciones agradables / multi-núcleo de código nativo / GC. (Niza cita: "Aspiramos a ninguna obra original, en lugar de utilizar la mayor cantidad de los últimos 30 años de investigación como sea posible.") Están buscando una velocidad de 5x-hasta CPython

.

Por supuesto, esto no soluciona su problema inmediato, pero apunta hacia un "cierre de la brecha" (si los hay) en el futuro (esperemos).

La belleza de hoy en dia pitón es lo bien que se comunica con otros idiomas. Por ejemplo, puede tener tanto Python y Java en la misma mesa con Jython. Por supuesto jython a pesar de que es totalmente compatible con las bibliotecas de Java no es compatible con las bibliotecas totalmente pitón. Pero es una solución ideal si quiere meterse con bibliotecas de Java. Incluso le permite mezclar con código Java sin codificación adicional.

Pero incluso Python sí ha dado algunos pasos forwared. Ver ctypes por ejemplo, cerca de la velocidad C, accees directos a bibliotecas de C todo esto sin salir de la comodidad de codificación pitón. Cython va un paso más allá, lo que permite mezclar código C con código Python con facilidad, o incluso si usted no quiere meterse con C o C ++, todavía se puede código en Python, pero usar de forma estática escribir variables de hacer sus Programms pitón tan rápido como aplicaciones C . Cython se utiliza tanto con el apoyo de Google por cierto.

Ayer encontré incluso herramientas para el pitón a inline C o incluso Asamblea (ver CorePy), no puede obtener ninguna más potente que eso.

Python es sin duda un lenguaje muy madura, no sólo de pie en sí mismo, pero capaz de coooperate con cualquier otro lenguaje de fácil. Creo que es lo que hace Python una solución ideal incluso en un muy avanzado y escenarios exigentes.

Con pitón puede tener acesso a C / C ++, Java, .NET y muchas otras bibliotecas con casi cero de codificación adicional que le da también una lengua que reduce al mínimo, simplifica y embellece la codificación. Es un lenguaje muy tentador.

Lo que Python, aunque GWT parece una combinación perfecta para el tipo de una aplicación que estoy desarrollando. JPA está bastante mal estado en GAE (por ejemplo, no hay limitaciones no documentados oscuros @Embeddable y otros). Después de haber pasado una semana, puedo decir que Java simplemente no se siente bien en GAE en este momento.

Uno piensa tener en cuenta son los marcos que la intención yo uso. No todos los marcos en el lado de Java son muy adecuadas para aplicaciones que se ejecutan en App Engine, que es algo diferente que los servidores tradicionales de aplicaciones Java.

Una cosa a tener en cuenta es el tiempo de inicio de la aplicación. Con las aplicaciones web tradicionales de Java que realmente no necesita pensar acerca de esto. La aplicación se inicia y entonces, sólo se ejecuta. Realmente no importa si el arranque tarda 5 segundos o par de minutos. Con App Engine que podría terminar en una situación en la que la aplicación sólo se inicia cuando llega una petición. Esto significa que el usuario está esperando, mientras que las botas de aplicación de hasta. Nueva GAE características como las instancias reservadas ayudan aquí, pero consulte primero.

Otra cosa son las diferentes limitaciones psoes GAE en Java. No todos los marcos están contentos con las limitaciones sobre lo que las clases se puede utilizar o el hecho de que los hilos no están autorizados o que no pueden tener acceso a sistema de archivos local. Estas cuestiones son probablemente fáciles de encontrar a cabo por simplemente buscando en Google acerca de la compatibilidad GAE.

También he visto algunas personas se quejan de problemas con el tamaño de la sesión en la interfaz de usuario marcos modernos (Wicket, a saber). En general, estos marcos tienden a hacer ciertas concesiones con el fin de burlarse de desarrollo, rápido y fácil. A veces esto puede dar lugar a conflictos con las limitaciones de App Engine.

inicialmente empecé a trabajar en el desarrollo de GAE con Java, pero luego cambié a Python debido a estas razones. Mi sentimiento personal es que Python es una mejor opción para el desarrollo de App Engine. Creo que Java es más "en casa", por ejemplo en Amazon Elastic Beanstalk.

y con las cosas de App Engine están cambiando muy rápidamente. GAE está cambiando sí mismo y como se hace más popular, los marcos también están cambiando a trabajar en torno a sus limitaciones.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top