Glyph Lefkowitz最近写了一篇启蒙文章，其中他详细的说明了一些关于开发高并发软件的挑战，如果你开发软件但是没有阅读这篇问题，那么我建议你阅读一篇。这是一篇非常好的文章，现代软件工程应该拥有的丰富智慧。
从多个花絮中提取，但是如果我斗胆提出主要观点的总结，其内容就是：抢占式多任务和一般共享状态结合导致软件开发过程不可管理的复杂性， 开发人员可能更喜欢保持自己的一些理智以此避免这种不可管理的复杂性。抢占式调度对于哪些真正的并行任务是好的，但是当可变状态通过多并发线程共享时，明确的多任务合作更招人喜欢 。
尽管合作多任务，你的代码仍有可能是复杂的，它只是有机会保持可管理下一定的复杂性。当控制转移是明确一个代码阅读者至少有一些可见的迹象表明事情可能脱离正轨。没有明确标记每个新阶段是潜在的地雷：“如果这个操作不是原子操作，最后出现什么情况？”那么在每个命令之间的空间变成无尽的空间黑洞，可怕的Heisenbugs出现
在过去的一年多，尽管在Heka上的工作（一个高性能数据、日志和指标处理引擎）已大多数使用GO语言开发。Go的亮点之一就是语言本身有一些非常有用的并发原语。但是Go的并发性能怎么样，需要通过支持本地推理的鼓励代码镜头观察。
并非事实都是好的。所有的Goroutine访问相同的共享内存空间，状态默认可变，但是Go的调度程序不保证在上下文选择过程中的准确性。在单核设置中，Go的运行时间进入“隐式协同工作”一类， 在Glyph中经常提到的异步程序模型列表选择4。 当Goroutine能够在多核系统中并行运行，世事难料。
Go不可能保护你，但是并不意味着你不能采取措施保护自己。在写代码过程中通过使用一些Go提供的原语，可最小化相关的抢占式调度产生的异常行为。请看下面Glyph示例“账号转换”代码段中Go接口（忽略哪些不易于最终存储定点小数的浮点数）
func Transfer(amount float64, payer, payee *Account,
server SomeServerType) error {
if payer.Balance() < amount {
return errors.New("Insufficient funds")
}
log.Printf("%s has sufficient funds", payer)
payee.Deposit(amount)
log.Printf("%s received payment", payee)
payer.Withdraw(amount)
log.Printf("%s made payment", payer)
server.UpdateBalances(payer, payee) // Assume this is magic and always works.
return nil
}
这明显的是不安全的，如果从多个goroutine中调用的话，因为它们可能并发的从平衡调度中得到相同的结果，然后一起请求更多的已取消调用的平衡变量。最好是代码中危险部分不会被多goroutine执行。在此一种方式实现了该功能：
type transfer struct {
payer *Account
payee *Account
amount float64
}
var xferChan = make(chan *transfer)
var errChan = make(chan error)
func init() {
go transferLoop()
}
func transferLoop() {
for xfer := range xferChan {
if xfer.payer.Balance < xfer.amount {
errChan <- errors.New("Insufficient funds")
continue
}
log.Printf("%s has sufficient funds", xfer.payer)
xfer.payee.Deposit(xfer.amount)
log.Printf("%s received payment", xfer.payee)
xfer.payer.Withdraw(xfer.amount)
log.Printf("%s made payment", xfer.payer)
errChan <- nil
}
}
func Transfer(amount float64, payer, payee *Account,
server SomeServerType) error {
xfer := &transfer{
payer: payer,
payee: payee,
amount: amount,
}