> The only way to move data to another thread is by passing it through > unsafeIsolate(). As a programmer I make a lot of stupid mistakes all the > time, one of which might be assuming that my data is isolated, while in > reality it is not. This will now result in an unsafe program that crashes or > shows other kinds of unpredictable behavior.
Actually you can also use `isolate` and `isolate` is not nearly as useless as you think it is but you need to adapt the coding style so that message construction happens in a dedicated proc. Except for when the very concept of isolation is useless -- when your data is not isolated. > I am not suggesting this should be solved by the type system, as I understand > this is a hard problem: instead, in my initial post I suggested that atomic > refs would be able to help with this. Atomic refs enable sharing but not isolation. Also, if you accidentically mutate accross threads the atomic refcounting isn't good enough to suddenly make your program correct! You need explicit syncronization code (locks, atomic stores, compare-and-swap, etc) anyway. > As an alternative I can imagine a safe runtimeIsolate() that validates if a > tree actually is isolated, or throw an exception if it is not. I do not know > how to implement this though. I do know how to implement that, but it's somewhat hard to do and before anybody even tried it in practice we'll hear horror stories like "Look, Nim introduced a whole new category of runtime errors! I never had to worry about this isolation stuff in C#/Java/C++, it's crap." The mechanism also needs to traverse the subgraph that we're about to move turning the O(1) move operation into the very O(n) subgraph operation that we tried to avoid by moving! But again, why should I be bothered to implement anything like that when you can already run plenty of realworld experiments. "It doesn't work anymore after a refactoring because I make mistakes" is irrelevant at this point as I'm interested in evaluating if isolation itself is worth pursuing.
