Python vs. Java - ¿Qué elegirías para hacer una programación concurrente y por qué?

Question

Además, si no es python o java, ¿generalmente elegiría un lenguaje de tipo estático o un lenguaje de tipo dinámico?

Answer 1

Elegiría la JVM sobre python, principalmente porque la multitracción en Python está impedida por el Global Interpreter Lock. Sin embargo, es poco probable que Java sea el mejor cuando se ejecuta en JVM. Clojure o Scala (usando actores) es probable que sean más adecuados para problemas de subprocesos múltiples.

Si elige Java debería considerar hacer uso de las bibliotecas java.util.concurrent y evitar las primitivas multihilo como sincronizadas.

Answer 2

Definitivamente Stackless Python! Que una variante de Python especialmente hecha para la concurrencia.

Pero al final depende de su plataforma de destino y de lo que esté tratando de lograr.

Answer 3

Si no es Java/Python iría por un lenguaje funcional ya que tener en cuenta los efectos secundarios es una de las complejidades de escribir software concurrente. (En lo que respecta a su pregunta: esta pasa a ser tipica, pero el compilador es la mayor parte del tiempo)

Personalmente, elegiría F #, ya que he visto muchos buenos ejemplos de cómo escribir software simultáneo con facilidad usando eso.

Como introducción: este hombre es equally fun as inspiring, incluso debe haberlo visto si no está interesado en F #.

Answer 4

No creo que el argumento sea acerca de la elección del lenguaje o el tipado estático o dinámico, sino entre dos modelos de concurrencia: memoria compartida y paso de mensajes. ¿Qué modelo tiene más sentido en su situación? & ¿El idioma elegido le permite elegir o se ve obligado a adoptar un modelo sobre el otro?

Por qué no echar un vistazo a Erlang (que tiene tipado dinámico) y message passing, la Actor model, y leer por qué Joe Armstrong doesn't like shared memory. También hay una discusión interesante sobre la concurrencia de Java usando bloqueos e hilos here on SO.

No sé acerca de Python, pero Java, junto con el modelo de bloqueos e hilos incorporados, tiene un marco de paso de meseta llamado Kilim.

Answer 5

Usaría Java, a través de Jython. Java tiene capacidades de subprocesos fuertes, y se puede escribir utilizando la sintaxis de Python con Jython, por lo que tiene lo mejor de los dos mundos.

Python en sí no es muy bueno con la concurrencia, y es más lento que Java de todos modos.

Pero si tienes problemas de concurrencia y manos libres, echaré un vistazo a Erlang porque ha sido diseñado para tales problemas. Por supuesto, debe tener en cuenta Erlang sólo si tiene:

• tiempo para dominar un (muy) nuevas tecnologías
de control
• en una parte razonable de la cadena de producción, desde Erland necesitan algunas adaptaciones en su caja de herramientas para adaptarse

Answer 6

Para concurrencia, yo usaría Java. Con el uso de Java, en realidad me refiero a Scala, que toma mucho de las construcciones de simultaneidad de Erlang, pero es (probablemente) más accesible para un desarrollador de Java que nunca antes ha utilizado.

Los subprocesos de Python sufren por tener que esperar el bloqueo de intérprete global, lo que hace que la concurrencia real (en un solo proceso) sea inalcanzable para los programas vinculados a la CPU. Según tengo entendido, Stackless Python resuelve algunas (aunque no todas) las deficiencias de concurrencia de CPython, pero como no lo he usado, no puedo aconsejarlo.

Answer 7

Para algunas tareas, Python es demasiado lento. Su único programa Java de hilo podría ser más rápido que la versión simultánea de Python en una computadora multi-core ...

Me gustaría usar Java o Scala, F # o simplemente ir a C++ (MPI y OpenMPI).

Answer 8

El entorno Java (bibliotecas JVM +) es mejor para la concurrencia que (C) Python, pero el lenguaje Java es una mierda. Probablemente iría con otro idioma en JVM: Jython ya se mencionó, y Clojure y Scala tienen un excelente soporte para concurrencia.

Clojure es particularmente bueno - tiene soporte para estructuras de datos persistentes de alto rendimiento, agentes y memoria transaccional de software. Es un lenguaje dinámico, pero puede darle sugerencias de tipo para obtener un rendimiento tan bueno como Java.

Vea this video en InfoQ por Richard Hickey (creador de Clojure) sobre los problemas con los enfoques tradicionales de concurrencia, y cómo Clojure lo maneja.

Answer 9

Me gustaría ver Objective-C y Foundation Framework. La programación concurrente asincrónica está bien prevista.

Esto, por supuesto, depende de su acceso a las herramientas de desarrollo de Apple o GnuStep, pero si tiene acceso a cualquiera de ellos, es una buena ruta para realizar con la programación simultánea.

Answer 10

Ninguno. La programación concurrente es notoriamente difícil de corregir. Existe la opción de utilizar un lenguaje de programación orientado a procesos como occam-pi que se basa en la idea de communicating sequential processes y pi calculus. Esto permite el tiempo de compilación para detectar interbloqueo y muchos otros problemas que surgen durante el desarrollo de sistemas concurrentes. Si no te gusta el occam-pi, que no puedo culparte si no lo haces, puedes probar Go el nuevo idioma de google que también implementa una versión de CSP.

Answer 11

La respuesta es que depende. Por ejemplo, ¿está tratando de aprovechar múltiples núcleos o CPU en una sola máquina o quiere distribuir su tarea entre muchas máquinas? ¿Qué tan importante es la velocidad frente a la facilidad de implementación?

Como se mencionó anteriormente, Python tiene el bloqueo de intérprete global, pero puede utilizar el módulo multiprocessing. Tenga en cuenta que aunque Stackless es muy bueno, es won't utilise multiple cores por sí mismo. Python generalmente se considera más fácil de trabajar que Java. Si la velocidad es una prioridad, Java suele ser más rápido.

La biblioteca java.util.concurrent en Java hace que la escritura simultánea de aplicaciones en una sola máquina sea más sencilla, pero igual tendrá que sincronizarse en torno a cualquier estado compartido. Si bien Java no es necesariamente el mejor idioma para la concurrencia, existen muchas herramientas, bibliotecas, documentación y mejores prácticas para ayudar.

Usar el paso de mensajes y la inmutabilidad en lugar de hilos y el estado compartido se considera el mejor enfoque para programar aplicaciones concurrentes. A menudo se prefieren los lenguajes funcionales que desalientan la mutabilidad y los efectos secundarios. Si la distribución de sus aplicaciones simultáneas en varias máquinas es un requisito, vale la pena mirar los tiempos de ejecución diseñados para esto, p. Erlang o Scala Actors.