One of the things that this blog ought to have clearly mentioned is that all this business about static analysis, ownership types, read-write annotations, purit

One of the things that this blog ought to have clearly mentioned is that all this business about static analysis, ownership types, read-write annotations, purity, immutability and all that is due to a simple conflation of two axes that ought to be orthogonal: mutation and aliasing. This is what Rust gets right: you can have an object be mutable (in which case you have only one pointer to it), or you can multiply alias pointers, all of which can only read the object. The type system enforces a static RW locking scheme in a manner of speaking; it ensures that only one of those capabilities is available at any one point in time. In other words, Rust ensures that mutation by itself is not a problem, that passing mutable structures between threads is statically checked for safety. You don't _have_ to make an object immutable in order to share safely by reference. --------------- It'd have been nice to hear about the "P" language, also from MSR (https://www.microsoft.com/en-us/research/publication/p-safe-asynchronous-event-driven-programming/ https://www.microsoft.com/en-us/research/publication/p-safe-...). No pointers, just value types, communicating state machines, produces model-checkable code. What's not to like?