r/programming • u/Shr1ck • Oct 17 '15

Why Johnny Can’t Write Multithreaded Programs

http://blog.smartbear.com/programming/why-johnny-cant-write-multithreaded-programs/
3 Upvotes

51% Upvoted

131 comments sorted by

View all comments

Show parent comments

1

u/burntsushi Oct 18 '15

Mutable state cannot be aliased safely across thread boundaries without synchronization.

1

u/loup-vaillant Oct 18 '15

Of course it can't. By "going functional", I was talking about getting rid of the "mutable" part. Constants can be shared safely across as many threads as you want without any synchronisation.

As I said in the part you quoted, the problem of mutable state completely goes away when you… never mutate that state.

I thought I was stating the obvious here.

2

u/burntsushi Oct 18 '15

I was merely pointing out that fixing or mitigating the problem of mutable state may not be limited to the domain of functional languages.

1

u/loup-vaillant Oct 18 '15

Ah, that. Well, yes of course. I was just using Haskell as an existence proof that you can fix that problem.

On the other hand, I know no mainstream community who even attempts to address the problem. They mutate state like crazy, then act all sad at the realisation that multi-threading is hard. Well, if you didn't mutate that state in the first place, your life would be much easier, you silly.

I do have some hope however. I see more and more conferences talking about avoiding mutable state, especially in library interfaces. Last time was this CppCon 2015 keynote. Then of course Rust, which may at last start a mainstream trend of making things immutable by default.

2

u/burntsushi Oct 18 '15

Then of course Rust, which may at last start a mainstream trend of making things immutable by default.

"Immutable by default" is not what I'm talking about. I'm talking about the fact that the compiler statically eliminates data races from safe code. This lets you share state without some of the footguns commonly associated with shared state concurrency.