4 ms·

Whether or not this is "fearless" depends on your point of view. As a long-time pthreads programmer, these systems feel like skittish concurrency. It's for fol

Whether or not this is "fearless" depends on your point of view. As a long-time pthreads programmer, these systems feel like skittish concurrency. It's for folks who are too afraid to use the underlying concurrency primitives, like shared memory, synchronization of some kind provided by OS, threads.

felixgallo 8y ago
Exactly. Because the recorded history shows those constructs are nearly impossible to use correctly.
- Animats 8y ago
  Yes. Having spent too much time debugging code by people who thought they were clever enough not to need language safety, I want language-level protection. (Did the Python crowd ever fix the race condition in CPickle?[1] They were in denial about this about eight years ago when I reported it. Doing multiple CPickle operations in separate threads can crash CPython. If you search for "CPickle thread crash" you find many reports of hard to reproduce problems in that area.) [1] https://bugs.python.org/issue23655 https://bugs.python.org/issue23655
  - int_19h 8y ago
    I don't see a denial in that bug report - they're just saying that they don't have an actionable repro, and don't know how to get one.
- pizlonator 8y ago
  False. Lots of software uses pthreads and its direct wrappers. Correctly? What does anyone ever do correctly in software? Does anyone write GUIs correctly? Does anyone do databases correctly? Proving even simple software correct is an enormous endeavor that most pragmatic programmers simply never have the luxury to do. So proclaiming that threads are bad because nobody does them “correctly” is setting an arbitrarily high standard. Or maybe you just don’t know what that word means.
  - felixgallo 8y ago
    Are you saying that buggy software is good because it’s widespread, and then trying to ad hominem me? Because that’s adorable both ways.
stingraycharles 8y ago
On the other hand, a powerful concurrency abstraction can make it much easier to reason about a large system. But I agree that the “fearless” part is mostly unjustified.
justryry 8y ago
While those primitives you mention make it possible to get a correct result, they require consistent and correct use from the programmers. While some of us may do this perfectly most of the time, bugs are inevitably created. This is reality. Fearless concurrency means guaranteeing many of those problems cannot occur. That frees up brain cycles, eases maintenance, reduces bugs, and perhaps even opens up concurrency to a wider audience or set of use cases.
- pizlonator 8y ago
  Every Turing complete primitive makes it possible to get an incorrect result. Every Turing complete primitive inevitably generates bugs. That’s the reality. Singling our threads because they also obey that basic law of computer science is a little selective, don’t you think? I understand what the thing they call “fearless concurrency” is. And I will repeat again: it’s skittish concurrency. It’s for fearful people.
tombert 8y ago
Couldn't the same argument be made for manual memory management? Couldn't I say that GC'd languages are for "people too afraid to handle pointer juggling"? I've done a fair amount of pthread work, and I coded myself into enough hard-to-debug issues in C that when I discovered I could fairly-easily structure my stuff around ZeroMQ, and then later discovering a book on different process calculi, I decided that there's no way I can go back to doing the low-level stuff. I'm just not smart enough to handle any kind of elaborate threaded programming.
- pizlonator 8y ago
  Nobody who promotes GCs calls it “fearless memory management”. So no. The same thing cannot be said for GC.
dxhdr 8y ago
> As a long-time pthreads programmer, these systems feel like skittish concurrency. I interpreted "fearless" to mean the opposite of "defensive programming." You have to be pathologically defensive when coding with basic synchronization primitives. These languages provide an alternative that frees you from that mindset. I only have experience with Erlang/OTP but it has been mind expanding when it comes to writing complex, robust, concurrent code. In fact one of the core Erlang style principles is "do not program defensively." Try that with pthreads!
goatlover 8y ago
Isn't it better to let the computer handle things humans are bad at unless you have a real good reason to muck around in the lower level?
- dunefox 8y ago
  No, because that would make sense. You MUST shoot yourself in the foot at absolutely every opportunity that presents itself or you're too afraid.
  - goatlover 8y ago
    Real programmers use Assembly/C/Fortran 77 for everything.
pornel 8y ago
Rust's primitives are all thin wrappers on top of libpthread. The difference is that the type system ensures you don't forget them, and makes it harder to misuse them (such as accessing data without locking its mutex, or mutating shared memory in a non-atomic way). And even if you think you never make mistakes, and it's always the other programmers who are the problem, Rust keeps other peoples' code in check too.

felixgallo 8y ago

Exactly. Because the recorded history shows those constructs are nearly impossible to use correctly.

Animats 8y ago
Yes. Having spent too much time debugging code by people who thought they were clever enough not to need language safety, I want language-level protection. (Did the Python crowd ever fix the race condition in CPickle?[1] They were in denial about this about eight years ago when I reported it. Doing multiple CPickle operations in separate threads can crash CPython. If you search for "CPickle thread crash" you find many reports of hard to reproduce problems in that area.) [1] https://bugs.python.org/issue23655 https://bugs.python.org/issue23655
- int_19h 8y ago
  I don't see a denial in that bug report - they're just saying that they don't have an actionable repro, and don't know how to get one.
pizlonator 8y ago
False. Lots of software uses pthreads and its direct wrappers. Correctly? What does anyone ever do correctly in software? Does anyone write GUIs correctly? Does anyone do databases correctly? Proving even simple software correct is an enormous endeavor that most pragmatic programmers simply never have the luxury to do. So proclaiming that threads are bad because nobody does them “correctly” is setting an arbitrarily high standard. Or maybe you just don’t know what that word means.
- felixgallo 8y ago
  Are you saying that buggy software is good because it’s widespread, and then trying to ad hominem me? Because that’s adorable both ways.

stingraycharles 8y ago

On the other hand, a powerful concurrency abstraction can make it much easier to reason about a large system. But I agree that the “fearless” part is mostly unjustified.

justryry 8y ago

While those primitives you mention make it possible to get a correct result, they require consistent and correct use from the programmers. While some of us may do this perfectly most of the time, bugs are inevitably created. This is reality. Fearless concurrency means guaranteeing many of those problems cannot occur. That frees up brain cycles, eases maintenance, reduces bugs, and perhaps even opens up concurrency to a wider audience or set of use cases.

pizlonator 8y ago
Every Turing complete primitive makes it possible to get an incorrect result. Every Turing complete primitive inevitably generates bugs. That’s the reality. Singling our threads because they also obey that basic law of computer science is a little selective, don’t you think? I understand what the thing they call “fearless concurrency” is. And I will repeat again: it’s skittish concurrency. It’s for fearful people.

tombert 8y ago

Couldn't the same argument be made for manual memory management? Couldn't I say that GC'd languages are for "people too afraid to handle pointer juggling"? I've done a fair amount of pthread work, and I coded myself into enough hard-to-debug issues in C that when I discovered I could fairly-easily structure my stuff around ZeroMQ, and then later discovering a book on different process calculi, I decided that there's no way I can go back to doing the low-level stuff. I'm just not smart enough to handle any kind of elaborate threaded programming.

pizlonator 8y ago
Nobody who promotes GCs calls it “fearless memory management”. So no. The same thing cannot be said for GC.

dxhdr 8y ago

> As a long-time pthreads programmer, these systems feel like skittish concurrency. I interpreted "fearless" to mean the opposite of "defensive programming." You have to be pathologically defensive when coding with basic synchronization primitives. These languages provide an alternative that frees you from that mindset. I only have experience with Erlang/OTP but it has been mind expanding when it comes to writing complex, robust, concurrent code. In fact one of the core Erlang style principles is "do not program defensively." Try that with pthreads!

goatlover 8y ago

Isn't it better to let the computer handle things humans are bad at unless you have a real good reason to muck around in the lower level?

dunefox 8y ago
No, because that would make sense. You MUST shoot yourself in the foot at absolutely every opportunity that presents itself or you're too afraid.
- goatlover 8y ago
  Real programmers use Assembly/C/Fortran 77 for everything.

pornel 8y ago

Rust's primitives are all thin wrappers on top of libpthread. The difference is that the type system ensures you don't forget them, and makes it harder to misuse them (such as accessing data without locking its mutex, or mutating shared memory in a non-atomic way). And even if you think you never make mistakes, and it's always the other programmers who are the problem, Rust keeps other peoples' code in check too.