Groups   66 of 99+      julia-users ›  Concurrency  Julia with vs. Python 3.5, Go, Erlang Elixir 5 posts by 4 authors      Páll Haraldsson    9 14 15     First Julia claims good support with Python by using PyCall . As Python 3.5 was just released I wander if that still holds or needs fixing:  https:  www.python.org dev peps pep-0492   for concurrency  or otherwise . I know I could just check out.. but  in general I wander how appropriate Julia is now, instead of  or with best-in-class languages : Erlang etc.   I think Julia's focus is serial AND parallel coding  but concurrency to a lesser degree? I'm aware there are changes in 0.4 .  I know concurrency is not the same as parallel, but needed for it or useful on its own.  I understand Erlang  or Elixir,  based on it  , maybe the best language implementation for concurrency, what it's made for. Julia may not compare, just yet. Maybe something is needed but it has the right foundation? Or not  has mutable state.. .   Some really like Golang  for those who do not like a functional language , for stuff like this, and it has N:M threading. Is that a showstopper for Julia? Any benchmarks on how scalable Julia is vs. Go? Any idea how difficult it would be to add N:M threading?  --  Palli.        Isaiah    9 14 15   Please post such open-ended or X-vs-Y opinion questions to a different venue, such as reddit or a personal blog.      Andrei Zh    9 15 15   It would be more productive, if you could describe what exactly you expect from a good concurrent parallel programming language. Julia already has built-in coroutines  Tasks  and multiprocessing, and will get shared-memory parallelism  multithreading  in observable future. The only thing in other languages that is missing from Julia is supervision  e.g. like in Erlang , but it looks easily doable on user level and really depends on what you want to achieve.       Páll Haraldsson    9 15 15   On Tuesday, September 15, 2015 at 9:56:12 AM UTC, Andrei Zh wrote: It would be more productive, if you could describe what exactly you expect from a good concurrent parallel programming language. Julia already has built-in coroutines  Tasks  and multiprocessing, and will get shared-memory parallelism  multithreading  in observable future. The only thing in other languages that is missing from Julia is supervision  e.g. like in Erlang , but it looks easily doable on user level and really depends on what you want to achieve.     About Python 3.5, that was really a pointer for Tim Holy..     Thanks for answering, and confirming what I thought. You'll don't really have to read further, I got the message that julia-users might not be the best place, I just posted again because there was an answer.   I didn't really think Golang could be theoretically better, it seems Julia already has what Golang can do or at least, few things missing, could add added to Julia. That is, they have SMP threads and Julia only green threads, but the former a requirement for N:M threading, while N:M threading in itself isn't a strict requirement for anything  only to get more concurrency . I'm not to familiar with goroutines vs. coroutines, and see that Channels have been added in Julia.   Parallelism, concurrency and threads with shared state, are a can of worms.. and I'm not an expert and just thinking what the right abstractions are in a language and if Julia has them or at least doesn't rule them out  I don't think there is a good reason to stay away from Julia .   I understand Haskell is supposed to be better for parallel because it is a pure functional language. Easier to prove your program right  same with Erlang . And allows software transactional memory  STM . I wander what the truth is, as mutable state can also be good.. at least when you use more than half of your memory, then sorting in-place is good.. And Lazy-jl  that I've not really looked at  might allow all that Haskell has to offer?   Would Julia be better for HPC parallel and other languages  always be  better for some other things - e.g. concurrent..   Julia also has immutability  strings  and functions ending in !  not enforced.. at least yet . Maybe they allow all the benefits a pure functional language could potentially have?    By supervision, what do you mean? I understand Erlang has stuff like hot loading of new code, allowing a new versions of your code with older  one version back  still running. Java even has hot-loading  not this fancy?  and I assume Julia could do the same and all the fault-tolerence features, but it has just not been implemented yet..      When I saw Python 3.5 was out, that was the original reason for this post.. then it snowballed.. Note, also that it added a   operator for matrix multiply. At least Python 3.5 should work with Julia for all old code I assume.. Or maybe even new, without needing any fixes in PyCall.   On Monday, September 14, 2015 at 2:58:52 PM UTC+3, Páll Haraldsson wrote:   First Julia claims good support with Python by using PyCall . As Python 3.5 was just released I wander if that still holds or needs fixing:  https:  www.python.org dev peps pep-0492   for concurrency  or otherwise . I know I could just check out.. but  in general I wander how appropriate Julia is now, instead of  or with best-in-class languages : Erlang etc.   I think Julia's focus is serial AND parallel coding  but concurrency to a lesser degree? I'm aware there are changes in 0.4 .  I know concurrency is not the same as parallel, but needed for it or useful on its own.  I understand Erlang  or Elixir,  based on it  , maybe the best language implementation for concurrency, what it's made for. Julia may not compare, just yet. Maybe something is needed but it has the right foundation? Or not  has mutable state.. .   Some really like Golang  for those who do not like a functional language , for stuff like this, and it has N:M threading. Is that a showstopper for Julia? Any benchmarks on how scalable Julia is vs. Go? Any idea how difficult it would be to add N:M threading?  --  Palli.        Kristoffer Carlsson    9 15 15   This post goes ALL over the place. Go, threads, Python,   operator, PyCall, Haskell, Erlang, immutable strings, mutating function convention with!, etc etc.  You keep posting these open ended posts that to be honest look a bit like rambling. Before you start writing, think about what your actual question is. Give a short introduction to the problem and state the question. Include everything that is needed and nothing more. It will benefit both you in that you will get better answers and the people reading that don't have to read unnecessary stuff.