checkedthreads

Personally I'd probably label MPI as "too low-level" an abstraction, not unlike threads; and I think there are many great high-level threading abstractions which I wouldn't call fragile, from Cilk/TBB and the like to transactional memory. What I meant to say was, Cilk/similar can be very useful at times, transactional memory at other times, Erlang-style fully isolated lightweight processes at still other times, etc. - and none of these approaches comes with a universally available interface, also none is universally taught (while threads are.) So my guess is that raw threads will be used increasingly less but (A) it will take time and (B) either we miss something right now or it will take more mechanisms and approaches to replace raw threads than it took to replace goto. That said, anyone needing to do something with threads today at any

Well, let's say you can't use numpy or similar - "C written by someone else" - and further, let's imagine a world where CPython has no GIL. Then there are 2 options: 1. You rewrite things in single-threaded C, getting a speed-up of 30-50x. 2. You rewrite things in multi-threaded Python, getting a speed-up of say 4-8x. I argue that 1 is often actually safer than 2, because parallelism-related bugs are harder to hunt down than C's memory-overwriting bugs (this can be mitigated with good APIs and a good race detector working against these APIs - as in Cilk or https://github.com/yosefk/checkedthreads - but it still requires good testing coverage). Now if 2 were more pleasant and safe than 1, I might agree with you even though 1 gives the better speed-up. But I believe 1 is faster and safer.