返回信息流喜大普奔，详情戳：Go 1.8 is released
简单做个翻译：
- 编译器跟链接器更快了，之前针对x86/64的优化现在在其他架构上也可以看到了
- 垃圾回收也更快了， 基本可以在100微秒完成，大部分情况会在10微秒以内（官方的blog措辞很严谨啊）
- http支持 push， 支持gracefuly shutdown
- 之前吊炸天的context现在也被用在更多的基础库里面，
- 还可以对slice方便的排序
怎么有种苹果开发布会的感觉呢？
p.s. 考研出分的小伙伴可以考虑入坑了[ema0][ema0][ema0][ema0][ema0][ema0][ema0][ema0]
这是一条镜像帖。来源：北邮人论坛 / golang / #755同步于 2017/2/17
该镜像源已超过 30 天没有更新，可能在源站已被删除。
Golang机器人发帖
1.8来了（是不是考研出分也是这一天）
nullne
2017/2/17镜像同步7 回复
订阅后，新回复会通过你的通知中心匿名送达。
7 条回复
是微秒。。。
【 在 nullne 的大作中提到: 】
: 喜大普奔，详情戳：Go 1.8 is released
: 简单做个翻译：
: - 编译器跟链接器更快了，之前针对x86/64的优化现在在其他架构上也可以看到了
: ...................
这你放心好了，对于垃圾回收来说，stack scan相对于整个gc过程，是最便宜的。
【 在 qiukun 的大作中提到: 】
: 10ms ...所以调用链不能太长（
Go 这个 GC 会收到对象数量的困扰嘛？感觉基础库或者高性能服务还是需要去管一管 alloc。
【 在 nuanyangyang 的大作中提到: 】
: 这你放心好了，对于垃圾回收来说，stack scan相对于整个gc过程，是最便宜的。
:
gc一次全heap扫描需要的时间是扫描之时活着的对象的数量。
但是gc很擅长处理大量的短命对象的分配和回收。所以，大多数基础库还是高性能服务，都可以放心大胆地使用gc。
尽可能不要手动alloc。确实，某些极特殊情况下，手动分配内存可以提高速度和内存利用率，但手动分配内存的代价比有GC辅助的内存分配高。原因是没有gc的分配器不能使用bump pointer分配器（除非是lifo allocator），只能使用free list。而free list会在内存分配的时候消耗大量时间，而且locality也不如bump pointer分配器好。相比之下，gc虽然有回收的代价，但内存分配效率高得多，使得程序整体执行效率提高。（见 https://bbs.byr.cn/#!article/CPP/90173 ）
【 在 qiukun 的大作中提到: 】
: Go 这个 GC 会收到对象数量的困扰嘛？感觉基础库或者高性能服务还是需要去管一管 alloc。