本文将并发和内存管理做了个类比。最近有一个说法是因为现代工程师几乎总是面对计算机集群编程，所以我们需要用于构建分布式系统的工具。这就意味着我们需要在语言层面支持分布式系统开发。像GO和Erlang这样的语言其优势正好符合这个观点。
GO和Erlang可能最终会流行，但我不认为是这个原因。分布式系统开发并不会成为每个应用开发者日常工作的一部分，因为那将会是件非常痛苦的事情。在某种程度上，我想今天发生的事情是因为缺乏良好的分布式计算框架，而迫使应用去重新实现一些分布式系统原语。但这种情况不会一直存在，而必将有一些框架提供不同的编程模型，在弹性机器池上处理分布和并发问题。
MapReduce已经解决了这个问题。MapReduce编程几乎都是单线程的，并发是由框架来管理，另外有助于你写好MapReduce程序的原因是，有很多用户级别(user-level)的并发原语，并且MapReduce是高度并行的。
这不是个新事物，即使是Java servlets，其所有的缺陷主要是因为抽象了线程模型，但是至少对于应用程序来说只需要通过阻塞I/O与一个数据库进行交互。
我觉得有三大基本领域需要处理：在线，近实时和离线。
- 在线领域，我们创建请求/响应式服务，并行性是通过将每个请求的处理当作一个工作单元，划分到不同的线程和机器。我见过该模型的多个变种，从“服务查询语言”到将REST调用拼接在一起的DSLs，它们的共同点就是抽象并发的处理，而不需要像线程一样直接访问单个服务器的并发机制。
- 在近实时处理领域，流处理框架做的很好，通过异步处理而根本不用考虑并发。而且你关心的并发和并行只在框架层面，你写的代码看起来完全是单线程的。
- 离线领域似乎为了不同的目标朝着YARN框架 （校对注：YARN框架介绍）的方向发展。
几乎所有这些框架的共同点是它们都不需要用户直接管理并发。
我认为这些高层次的领域（在线，异步和离线）将被证明会长期存在，但是我不认为我们需要十几个基础分布式计算框架来涵盖这些领域。
这让我花了很多时间来思考，在语言层面支持单机并发（软件事务内存和其他）效果是有限的。它只会帮助框架的实现者而不是最终用户。相比应用开发者，框架实现者会有一些非常不同的需求，他们更关心性能和细粒度的控制。尽管这显然是一个有争议的说法，我不确定线程和锁对框架开发者来说是否是一个可行的模型，毕竟，对于一个受训过的团队它们做的非常好，并有出色的性能和控制能力。
