3 ms·
I just doubt that those abstractions are easy and would say that they often break. Blaming the programmer for thread-unsafety in e.g. Java is like blaming progr
by legulere 8y ago
I just doubt that those abstractions are easy and would say that they often break. Blaming the programmer for thread-unsafety in e.g. Java is like blaming programmers for memory unsafety in C.
I agree if you stay in purely functional programming languages you run into points that are solved better with mutability. However those parts of a program are small and most parts are expressed better by pure functions.
- jschwartzi 8y agoI wouldn't say that they "often break" considering that we never had a single issue with our software that could be linked to any of our threading abstractions in the 4 years of rigorous development and testing. But rather it's important to be clear about how your abstractions are to be used, and that you don't inject a lot of special-case logic into it. In our case we had to accept significantly reduced performance in exchange for the abstractions, but in the end it was worth not having to debug everyone's thread-safe code separately. A lot of it came back to choosing an abstraction that was simple enough to be well-understood and about not pushing the envelope too far.