The following passage is interesting because it points away from the most widely held belief about concurrency and FP. I'd like to know more about what he means.
The other argument for a pure subset language has to do with advancing concurrency, but as I really started to dig in to concurrency support in BitC, I came increasingly to the view that this approach to concurrency isn't a good match for the type of concurrent problems that people are actually trying to solve, and that the needs and uses for non-mutable state in practice are a lot more nuanced than the pure programming approach can address. Pure subprograms clearly play an important role, but they aren't enough.
I imagine he means that pure programming can only address concurrency in some of the many areas of programming where we may wish to leverage some kind of concurrency. I personally see immutable state as an important fundamental building block to better concurrency support in languages, but certainly not the only building block.
One example of something which I would like to see is a linear type system for pointers to mutable data so that you can reference mutable shared state, but only one task/thread/function may access it at any one time and assigning or copying the pointer causes ownership to be transferred. I think this would be useful in a pipeline or dataflow system where the pipeline stages operate on a blob of memory directly, but its guaranteed that only one stage can ever access it at any one time. I guess its more or less an optimization on message passing immutable memory from stage to stage, so not exactly necessary, but still another building block I would like to see.
I'd also like to hear what Shapiro has in mind though.
so that you can reference mutable shared state, but only one task/thread/function may access it at any one time and assigning or copying the pointer causes ownership to be transferred
That sounds kind of like Rust's "unique pointers".
Yes, I think this is exactly Rust's unique pointers. Rust has a lot of interesting language features and is one of the up-and-coming languages I'm watching with interest.
Almost, but not quite. I'll quote a few key phrases from [1] to distinguish between what I want and transients, though I imagine in real life transients probably capture most use cases fairly well.
The second feature of transients is that creating one does not modify the source, and the source cannot be modified via use of the transient. Your source data is immutable and persistent as always.
Note in particular that transients are not designed to be bashed in-place.
The unique linear pointer would allow direct in-place mutation of the source. As it is guaranteed to be unique, no synchronization is needed. Transients do not modify in-place and do not allow you to mutate the source type directly, but allow you to add to the source and the added data is mutated directly for performance. There is a lot of overlap in use cases and transients are an excellent middle ground for Clojure, since it allows you to code against immutable types but with the performance benefits of partial mutation. The pointers I described would be less flexible in that you cannot have references to an immutable portion as you can in Clojure, but at the same time the owning code has completely mutable access.
In general, I love Clojures concurrency model and I don't think unique pointers would really mesh well with the rest of Clojure.
The other argument for a pure subset language has to do with advancing concurrency, but as I really started to dig in to concurrency support in BitC, I came increasingly to the view that this approach to concurrency isn't a good match for the type of concurrent problems that people are actually trying to solve, and that the needs and uses for non-mutable state in practice are a lot more nuanced than the pure programming approach can address. Pure subprograms clearly play an important role, but they aren't enough.