后端打好基础看 paper 吧， paper 营养大着呢，你看 google 三篇分布式论文就可以搞出一个大数据生态圈，最近一批 google manglev 又提供负载均衡的新思路。每看一篇论文都实现一次，还不碉堡啊？

纵观各家的解决方案，我认为还是硬件狗最实际，而且最好是要求客户签 EULA ， EULA 里面写明不允许逆向否则走法律途径。

@nlimpid 看了知乎专栏，专栏作者也是说入门了可以不买了，现在的话我觉得 Python 的书要不是解析器源码分析，要不是脑洞打开的设计思路，其他的基本或多或少自己都用过，标准库的文档也看得差不多。大概也是复习一次罢了了。__slots__这东西我第一次看到的时候是在 http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/这里看到的。主要是觉得就是这样的东西太多了，又不纳入语言标准。记得 PyPy 也是因为要模拟这个特性而速度会变慢，我个人是觉得能不用就尽量不用，甚至我觉得如果我要写 C 扩展的话，我都会尽量使用 cffi 。

自从工作之后，代码看多了，我都觉得很多东西都没什么。比如我们生产环境就有自己实现的模块热更新，使用了 Python 的动态特性，诠释何为 metaprogramming 。感觉要多了解 Python 还是得自己多动手啊。

有没有人能给我说一下《 Fluent Python 》的优点，因为现在知乎上面都是爬虫教程，没见到有人推荐这书。不过看了一下目录，感觉还是有点东西

@neoblackcap 这是因为本身 CPython 代码质量高，二来 C API 暴露的底层细节太多了，很多东西都得在 runtime 时候才能知道，没法优化，知乎上面的 R 大曾经发过多篇文章说这方面。

然后就是 GC 的问题了，既然 tracing GC 能回收垃圾，那么为什么还要用引用计数？要知道引用计数其实是将每次回收的成本摊分，有人做过比较，除非是内存很紧张，否则朴素 mark-swap 的效率都比引用计数好。毕竟在两个回收周期里面不管 heap 上的对象怎么变化， GC 只管开头结果两个状态。还有就是这个 GC 由引起 GIL 的问题，如果不是引用计数的话， GIL 压根可以不存在，多线程提高多核利用率也可以做。而且社区还是很抵制这些改变，这也是一个问题。 Pycon 2016 US 就有人做演讲在做移除 GIL 的事情， Guido 对他的工作要求是，移除是可以的，但是不要降低单进程下的效率。真是要求很高啊。

Python 不是 JIT 不能做，那是做 JIT 很大可能就要破坏现有的接口，动 C API ，那么就一大堆 C 扩展不能用，这个才是最大的问题。
而且 GC 改成 tracing gc 我觉得其实是挺好的，引用计数会有很多问题的，现代的 GC 大多是 tracing GC

3L 已经有人给出答案了，其实现在的超极本续航一直都不差，而且 dell 是有跟 ubuntu 合作的，因此驱动什么的还是可以的。当然你完全可以上 win 10 然后用 linux 子系统，一般的开发还是够用的，而且续航更好。

@forrestchang 我是没参加过，不过听过一位朋友分享他参加的经验，他是搞 wine 的，他当年是因为 wine 上面有他报的 200 个 issue 所以就进了。

有导师，你多试一下吧，很好的机会，还有 5000 美元

不要整天搞个大新闻，问问题就应该将你的最小可重复执行环境给贴出来

@chenqh gevent.joinall 只是等待所有请求啊？为什么就不能并发呢？搞不懂

访问 google ？我司应该几十毫秒吧。
不要总想着在愚人节搞个大新闻，你不 monkeypatch 又有多少程序能支持 gevent 啊。楼主你啊， too youny too simple, sometime naive 。还是要学习一个的。

@sagaxu 是的，但不是说 zero cost abstraction 是追求没有成本，它的追求应该是没有“额外”的抽象成本。

@sagaxu zero cost abstraction 不是这样的意思吧？应该是哪怕你用了某些特性，将问题抽象层次提高了，你的运行成本也没有改变，就像你对一堆二进制数据强制类型转换，将它看成一个 struct ，这个一个强制类型转换是在编译时完成的，因此没有额外的运行成本。
又或者是 C++里面的 template 或者 Rust 的宏，他们都是编译时完成的，但是运用他们的确可以提高我们的抽象层次。

做过，坑很大，这些相对于支付宝的风控都不是事

@whwq2012 其实少量拼接的时候+跟 join 的性能相差不大。