Hacker News Reader

Comment by pizlonator | Hacker News Reader

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.

View on HN

> 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!

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.

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?

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.

Real programmers use Assembly/C/Fortran 77 for everything.

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.

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

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

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

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com