[ACCEPTED]-Python vs. Java -- Which would you pick to do concurrent programming and why?-python-stackless

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

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

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

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

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

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

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

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

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

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

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

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

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

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

But if you have 4 concurrency issues and free hands, I'd have 3 a look at Erlang because it has been design 2 for such problems. Of course, you must consider 1 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

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

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

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

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

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

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

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

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

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

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

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

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