Maynard Handley (name99.delete@this.name99.org) on July 13, 2015 7:18 pm wrote:
> It's really only the case if you insist on working in a C-like language.

Hell no.

> With more sophisticated languages
> (a) the compiler can keep track of what state is stored where --- no raw
> pointers allowing for possible random writes from anywhere to anywhere
> (b) the compiler has knowledge of what is and is not mutable (and
> the language encourages the use of immutable structures)
>
> The end result is that
> - there is not that much state that NEEDS to be protected
> between possible threads (because most is immutable)
> - that which does need to be protected can be protected automatically
> by the compiler because it knows who is writing when

In practice, it is not that simple, neither Java or .Net (for example) does that, everything would be easier if most structures where immutable, but on most projects that's not the case.

> Coupled with the fact that in these languages people aren't writing their own cross-thread queues and MP-safe
> hashtables and suchlike --- they assume the language gives them that already, and the most explicit multi-threaded
> thing they ever do is to dump a block/lambda/anonymous function into some MP-queue.

That's the recommendation, but for some reason every time I have to write multi-threaded code almost never there are high level structures that does what I need, another case of "in practice, it is not that simple".

> And the higher up you go the less it's an issue. Just write a large map/reduce
> in your favorite functional language and you assume the system will do the right
> thing (worst case you might have to throw in a "parallel" keyword).

I like this aspect of functional languages, just write the obvious algorithm and the compiler make it multi-threaded, but I can't use functional languages as much as I would like.