Python vs. Java -- Which would you pick to do concurrent programming and why?

Question

Also, if not python or java, then would you more generally pick a statically-typed language or a dynamic-type language?

Answer 1

Definetely Stackless Python! That a Python variant especially made for concurrency.

But in the end it depends on your target platform and what you are trying to achieve.

Best wishes,
Fabian

Answer 2

If not Java/Python I would go for a functional language since taking side effects into account is one of the complexities of writing concurrent software. (As far as your question goes : this one happens to be statical typed, but compiler infered most of the time)

Personally I would pick F#, since I've seen lots of nice examples of writing concurrent software with ease using it.

As an introduction : this man is equally fun as inspiring, even a must have seen if you are not interested in F# what so ever.

Answer 3

I don't think the argument is about language choice or static or dynamic typing - it's between too models of concurrency - shared memory and message passing. Which model makes more sense in you situation & does your chosen language allow you to make a choice or are you forced to adopt one model over the other?

Why not have a look at Erlang (which has dynamic typing) and message passing, the Actor model, and read why Joe Armstrong doesn't like shared memory. There's also a interesting discussion about java concurrency using locks and threads here on SO.

I don't know about Python, but Java, along with the inbuilt locks and threads model, has a mesasge passing framework called Kilim.

Answer 4

I would use Java, via Jython. Java has strong thread capabilities, and it can be written using the Python syntax with Jython, so you got the best of the two worlds.

Python itself is not really good with concurrency, and is slower than Java anyway.

But if you have concurrency issues and free hands, I'd have a look at Erlang because it has been design for such problems. Of course, you must consider Erlang only if you have:

• time to master a (very) new technology
• control on a reasonable part of the production chain, since Erland need some adaptations in your toolbox to fit

Answer 5

I would choose the JVM over python, primarily because multi-threading in Python is impeded by the Global Interpreter Lock. However, Java is unlikely to be your best when running on the JVM. Clojure or Scala (using actors) are both likely to be better suited to multi-threaded problems.

If you do choose Java you should consider making use of the java.util.concurrent libraries and avoid multi-threading primitives such as synchronized.

Answer 6

For concurrency, I would use Java. By use Java, I actually mean Scala, which borrows a lot from Erlang's concurrency constructs, but is (probably) more accessible to a Java developer who has never used either before.

Python threads suffer from having to wait for the Global Interpreter Lock, making true concurrency (within a single process) unachievable for CPU-bound programs. As I understand, Stackless Python solves some (though not all) of CPython's concurrency deficiencies, but as I have not used it, I can't really advise on it.

Answer 7

For some tasks, Python is too slow. Your single thread Java program could be faster than the concurrent version of Python on a multi-core computer...

I'd like to use Java or Scala, F# or simply go to C++(MPI and OpenMPI).

Answer 8

The Java environment (JVM + libraries) is better for concurrency than (C)Python, but Java the language sucks. I would probably go with another language on the JVM - Jython has already been mentioned, and Clojure and Scala both have excellent support for concurrency.

Clojure is particularly good - it has support for high performance persistent data structures, agents and software transactional memory. It is a dynamic language but you can give it type hints to get performance as good as Java.

Watch this video on InfoQ by Richard Hickey (creator of Clojure) on the problems with traditional approaches to concurrency, and how Clojure handles it.

Answer 9

I'd look at Objective-C and the Foundation Framework. Asynchronous, concurrent programming is well provided for.

This of course depends on your access to Apple's Developer Tools or GnuStep, but if you have access to either one it's a good route to take with concurrent programming.

Answer 10

Neither. Concurrent programming is notoriously hard to get correct. There is the option of using a process oriented programming language like occam-pi which is based of the idea of communicating sequential processes and the pi calculus. This allows compile time checking for deadlock and many other problems that arise during concurrent systems development. If you do not like occam-pi, which I cant blame you if you dont, you could try Go the new language from google which also implements a version of CSP.

Answer 11

The answer is that it depends. For example are you trying to take advantage of multiple cores or cpus on a single machine or are you wanting to distribute your task across many machines? How important is speed vs. ease of implementation?

As mentioned before, Python has the Global Interpreter Lock but you could use the multiprocessing module. Note that while Stackless is very cool, it won't utilise multiple cores on its own. Python is usually considered easier to work with than Java. If speed is a priority Java is usually faster.

The java.util.concurrent library in Java makes writing concurrent applications on a single machine simpler but you'll still need to synchronise around any shared state. While Java isn't necessarily the best language for concurrency, there are a lot of tools, libraries, documentation and best practices out there to help.

Using message passing and immutability instead of threads and shared state is considered the better approach to programming concurrent applications. Functional languages that discourage mutability and side effects are often preferred as a result. If distributing your concurrent applications across multiple machines is a requirement, it is worth looking at runtimes designed for this e.g. Erlang or Scala Actors.