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 Go could be theoretically better, it seems Julia already has what Go 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 Go (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. >> >> >> >>
