Automatic concurrency management is the new thing, like automatic garbage collection was in the 90s
This is a great interview between Bill Venners and Rich Hickey. Hickey is the guy behind Clojure, the new JVM language that brings Lisp to the world of Java. I have so far only heard good things about Clojure. Hickey makes the argument that what is needed in modern languages is the automatic management of time and concurrency issues. In the same way that, during the early 90s, Java introduced (to the mainstrteam) the idea of automatic garbage collection, now we need languages to automatically manage the problem of multiple processes accessing the same object at the same time:
Bill Venners: What do you mean when you say the problem of mutable state is a time problem?
Rich Hickey: If somebody hands you something mutable—let’s say it has methods to get this, get that, and get the other attribute—can you walk through those and know you’ve seen a consistent object? The answer is you can’t, and that’s a problem of time. Because if there were no other actors in the world, and if time wasn’t passing between when you looked at the first, second, and third attribute, you would have no problems. But because nothing is captured of the aggregate value at a point in time, you have to spend time to look at the pieces. And while that time is elapsing, someone else could be changing it. So you won’t necessarily see something consistent.
For example, take a mutable Date class that has year, month, and day. To me, changing a date is like trying to change 42 into 43. That’s not something we should be doing, but we think we can, because the architecture of classes is such that we could make a Date object that has mutable year, month, and day. Say it was March 31, 2009, and somebody wanted to make it February 12, 2009. If they changed the month first there would be, at some point in time, February 31, 2009, which is not a valid date. That’s not actually a problem of shared state as much as it is a problem of time. The problem is we’ve taken a date, which should be just as immutable as 42 is, and we’ve turned it into something with multiple independent pieces. And then we don’t have a model for the differences in time of the person who wants to read that state and the person who wants to change it.
…The time problem is not easy to see in today’s mainstream languages because there are no constructs that make time explicit. It is implicit in the system. We don’t even know that’s what we’re doing when we use locks to try to make this work. Because what we’re trying to do is partition time up to say, I’m going to get a portion of time when I get to look at it, and you’re going to get a separate portion of time when you’ll get to write it. That time management we have to do manually. We have to use locks and come up with some kind of convention, because it’s not automatic. So that’s why I’m saying, the problem here is a lack of automatic time management. We have to do that manually, just like we had to call delete before we had garbage collection. Somebody allocated something, and we had to call delete. It was our problem. It was manual. Now when we want to change a date or look at a date coherently, we have this time management problem that we use locks to try to solve.
This idea has been gaining strength for at least 2 years now. Automatic thread management was one of the reasons why Sam Ruby argued that Erlang would be one of the key technologies of the next 5 years.