Experiments with Nimrod

Yes, but I'm not sure how that's relevant considering that rust is attempting to compete against C++. This is definitely an area where statically analyzable performance bounds are really important, including memory management, and GC becomes very difficult to defend. GC is not the only way to remove manual memory management, and if performance is a priority you'll be hard-pressed to find a GC that naturally has the tradeoffs your particular algorithm will need to work optimally.

In the end, GC solves a different problem than Rust does. GC says "I never want to think about memory." Rust says "I never want to deref a null pointer."

Firstly, it isn't even actually published yet, so I'm not sure why you'd use it as an example of why people shouldn't have tried other knwon techniques for avoiding data races.

Secondly, there are plenty of already known ways of mitigating data races in managed languages (incidentally, the "managed time" paper you describe actually has a really good survey of availabile mitigation techniques). Haskell is normally data race free. So is Erlang (99% of the time). Databases, and transactional systems in general, give you far more guarantees than simple data race freedom (especially in the face of high concurrency) without making it ludicrously hard to reason about (if you use a strong enough isolation level), and they do that through managed software.

All of these systems, as good as they are, have very important tradeoffs: * They trade off pure speed for higher throughput (generally speaking). * Even if they are totally race condition free internally, they are still susceptible to them when they interact with external systems (even other instances of their own runtimes). * They require you to significantly constrain how you write code in order to make it actually satisfy these properties.

And while points (1) and (2) actually have lots of similarities with the tradeoffs of garbage collection as a technique, point (3) does not (well, I guess you could argue about pointer math :)). I believe that this represents irreducible complexity in parallel programming.

As far as I can tell, Glitch is not different from transactional database systems, and arguably much worse since it's a pretty naive implementation. Restriction to commutative state updates is attactive in many cases, and they are easy to optimize, but there are tons of updates that aren't commutative (look at a reasonably complex database system, some of which actually do have notions of commutativity). Tasks are just another word for transactions (as you can see, boundaries are explicitly specified). Glitch claims it is different from this because they "do not address ordering changes made inside a transaction, nor coordinating multiple causally connected transactions into larger-scale processes." I find these claims very strange because at least as used in databases, explicit orderings are actually pretty uncommon (that's the whole point!) and Glitch is going to have the exact same issue if you try to use it with the rest of the system. Similarly, the article discusses how transactions need to be aborted and retried, but Glitch already does this.

Because the system does not have any knowledge of global ordering, replay order is fairly suboptimal (this was found to matter in practice in PostgreSQL, for example, which avoids lots of potential deadlocks and incorrectly reported serialization failures by reordering dependencies in this way). Additionally, to preserve all its invariants, the program must remember old state until the entire system is in a consistent state, which will lead to substantial memory ovheread over other systems. Fixed-point iteration is also intrinsically quite slow in many cases--I don't see any runtime analysis here but I suspect in practice it is going to be a far cry from even naive garbage collection techniques. Since the only reason to actually do concurrent programming is for performance (except, again, where interacting with external systems, at which point your runtime can't help you anyway) I don't think this can be usefully handwaved away. Unlike MVCC, Glitch does does not preserve an easily accessible view of old state (it's there but requires calculation to reach), I think this problem is not going to go away with a better compiler as the authors claim.

Most importantly, though, managed time fails point (3). From a cursory read through the paper, I'm pretty sure it also suffers from the same potential livelock issues that are the reason databases don't just restart transactions automatically (the phrase livelock doesn't occur anywhere in the paper but I'm assuming the authors are aware of it). It also seems to me that it would not be hard to create cyclic dependencies that freeze up your program forever; while this isn't necessarily worse than proceeding with totally invalid state, that doesn't give me great confidence that I can simply "plug and play" Glitch and hope for the same behavior I'd see in a sequential system. Most damningly, to quote the article:

"YinYang can be used to implement user interfaces, games, and even a compiler, but it is not clear how to express simple things like an in-place bubble sort! Many classic algorithms depend upon re-assignment in one time step and thus do not naturally transliterate well into Glitch; similar limitations occur in single-assignment languages."

Just to be clear: I'm a huge fan of transactions. I think they're great. I would love first class support for transactions in most programming languages. But while I think they're solving a much harder problem than garbage collection is (and certainly harder than the very restricted problem of preventing data races, which can be done much more easily if performance really isn't a factor by making every update atomic), calling them "automatic" is a bit of a stretch.

Its very obvious that this has become a case of Wikipedia editors ganging up.

Some of the articles that reference Nimrod are on Wikipedia.

    const FOOBAR = if 2 > 1: 10 else: 20