 |
| To AVOID the code-equivalent of this race-condition, use Akka Futures. |
"[You can] attempt to change the future, you will fail." --Mike Slinn, apparent determinist
It was a highly technical talk revolving around concurrency, everything that can go (easily) wrong and how to make sure that it goes right. Mike was a great guy and posted his slides as well.
The tl;dr: Futures will let you have deterministic multi-threading. If you can't tell, this is a big deal in that you can be confidant that your unit tests will mean that the app works correctly in production (no tricky race conditions!) However, futures don't scale to multiple mother-boards so it isn't a grid-computing solution. Futures are also composable and immutable (see quote above).
Concurrency is going to be increasingly important as the clock speed of silicon has basically been maxed out and Moore's Law is only continuing due to more cores, so if you want your program to run faster in the future than it does today you'll need to use concurrency. If you're going to use concurrency, make it as predictable and repeatable as possible (e.g. eliminate race conditions). Akka Futures let you do this.
Update: Mike Slinn also has a related article on InfoQ.
