这是我参与更文挑战的第1天，活动详情查看： 更文挑战

Go的map操作为什么不定义为原子操作?

经过漫长的讨论，我们决定maps平常的使用不需要保证多协程的并发安全。而当需要考虑多协程并发安全的时候，往往map是一个更大的数据结构或者计算过程的一部分，这这些早就被同步锁住了。因此如果要求所有的map操作都先获取一个互斥锁反而会降低大部分程序运行速度，而换来一丁点儿的安全提升。这其实不是一个简单的决定，因为它意味着不受控制的map设计可能会导致程序崩溃。

Go后续版本不会排除原子实现map。当需要的时候，比如运行一个不信任的代码的时候，一些方法可以实现map的访问互锁（PS:不是很懂 the implementation could interlock map access）。

map的不安全只有在进行map更新的时候会发生。只要所有的协程都是在读取一个map，或者用for-range遍历map的时候，不要去分配或者删除map的元素，那么map的并发操作就算不上同步锁也是安全的。

为了帮助用户发现map的错误使用，Go语言实现了一些方法会提醒用户在更新map的时候可能存在并发安全的问题。

preclude v 排除，阻止，妨碍
aid n 协助

你愿意体验Go语言吗?

人们提了很多想要提高Go的建议，例如groups.google.com/forum/#!for…

虽然Go是一个开源的项目，但是语言和内库都被“golang.org/doc/go1comp… 1 的规范，就算价值还不错，我们也不会满意并接受。未来Go一些主要的版本可能会不兼容Go 1，但是有一件事是确定的：不兼容的地方一定是十分少。此外，为了保证兼容性，我们会提供一个办法让老的程序适用新版本Go，这些都在讨论。

就算你的提议兼容Go 1版本，但是不符合Go的设计目标灵魂，也是不会接受的。talks.golang.org/2012/splash…

proposal n 提议
violate v 违法
specification n 规范
entertain v 是什么满意，高兴
incompatible 不兼容的
moreever 此外
even if 就算