@sjtlqy 我觉得 C++就压根不打算做这部分抽象工作，谁知道你想怎么样去调用底层部件。用 C++，你可以仅用轻量级线程去做网络编程，也可以用 IO 复用加系统线程去做网络编程。 C++是不假设你要干什么，它提供你自用，语言的作者本意就是不将个人的喜好强加于用户，喜欢面向对象的就去，喜欢元编程的就上。
因此我觉得这个也谈不上没做好，语言设计理念不一样。

上层 API 必须要将底层的 API 封装好，这个不是很正常嘛？
就算是 socket 也是有封装的，基本上你用到的都是网络层的东西，这就是封装。很正常
至于 IO 复用，当前版本的 go runtime 已经将其集成了。用 Goroutine 就可以了，调度器会自己去调度。

楼主你想听干货，不代表大家都想听干货。最近 v2 上的例子
http://v2ex.com/t/273893#reply16

干货本身就是一些小众的东西，会议为了热度自然会选择一些大家喜闻乐见的东西，毕竟那 300 又不是什么大钱，并不能有效地区分听众层面。 Qconf 之前好像是收 3000,自然能讲一些更干的东西。

其实 stackoverflow 都很干，但又有多少人会去研究学习。

@a302800411 知乎那流量不见得都是你看的内容，之前不是有个版本基本上 1 分钟上传一次日志吗？，一个日志 5MB 。这里面难保有什么肮脏的 PY 交易

就知乎那种 90%为文字的网站，流量能多到哪里去，但是他们的架构应该好好修改一下，不要整天报 502

@chewuhe 都说 windows 没有 fd 的限制，你看看你是不是耗光了内存了。 linux 等 Unix-like 系统才会有 fd 的数量限制，那个我记得是去改在 /etc/ssyctl.conf 里面的 net.core.somaxconn 参数（没有就自己加）

@cielpy 这样的文章你说『我就一个不写 GC ，就一个普通 web 开发者』又怎么会看。写这样的文章其实我是很赞成的，毕竟很多中级开发者很需要这样的文章，不过对于作者 @Draven 来说得到的成就感可能就不多了。毕竟中级开发者就那么点，他们还整天有业务任务，过来点赞真不多。
不过若是 @Draven 你以后跳槽什么的话，这样的文章倒是很好的加分项。不过我觉得你能写出这样的文章，大概已经是身居中级管理层，骨干之类了吧。

你在本地敲这样的命令，你的 shell 不就把你的$HOME 解析成你本地的 home 地址了吗？你服务器上面自然没有，你倒是用~替代你的$HOME 变量试试，当然，我是建议你直接敲绝对地址，一了百了。

桌面版的是 python2 ，服务器的是 python3 ，记得他们是这样说。毕竟要跟上流统一

1. 直接按普通的 mock 返回结果就可以了，比如像一楼说的。 tornado 测试的时候会堵塞 IOLoop 直到返回结果，你当同步代码来用就可以了。比如你将 gen.coroutine 换成 tornado.testing.gen_test ，那么你执行的代码的时候就是堵塞。

2. 之所以要 raise tornado.gen.Return 是一个 hack ，是 python 2.7 时代不允许 generator 里面有 return 的 hack ，因此就通过 raise 一个异常来解决这个问题。你若是使用 python 3.5 就可以直接 return 。而且你还可以使用 async 跟 await 两个关键字来达到更好的语义。

若是生成文件都在一个文件夹里面的话，你 add 那个文件夹就好了

@racechao @Draven 真是曲高和寡，好东西就是这样，最能吸引人的往往是最简单的。

@gevin 没有观点，选合适的， C++性能高但初学者用会很容易崩掉自己的腿。道理就是这样。我只是觉得仅仅一个结论不能达到你想要分享的初衷。
因为这样一个结论很多时候只能带来，『对啊， Django ORM 就是强』，『开玩笑， SQLAlchemy 才是最好的』，『 Pony ORM 才好，其他都是垃圾』这样无意义的回应。
记得一次与一位大牛聊天，他说编程中我们现在已经有很多资源了，但是好软件，好产品一样很少，这个原因就是人们缺少对事物的了解，以至于无法将资源合理利用。
所以我认为，我们在网上发表我们的观点时候是不是可以尽量地将我们的思考方式展现给大家呢？你是如何得出这个结论，我认为这才是关键，这才是大家想看到的『渔』之道。这样的文章无论是初学者还是中级谋求突破的开发者都会喜欢看到。
若是题主你能做到此步，我相信你的文章就会更精彩

@chewuhe windows 没有这个 fd 的限制，在 windows 上你操作的 sockets 仅跟你的机器资源有关
资料来源： https://msdn.microsoft.com/en-us/library/windows/desktop/ms739169(v=vs.85).aspx

@gevin 所以你要说明白，你一句 Django ORM 综合起来比 SQLAlchemy 强，新手还以为是 Django ORM 特性多，性能高。
很多时候就是这样，高灵活性以及低抽象成本必然伴随高的学习成本。
你分享你的具体看法观点，我们都来切磋切磋，这样你我才能进步嘛，仅抛一个结论就出来跟『 vim 大法好』这样有什么区别:-)

其他的我就不发表观点了，我只想说『 Django 的自带 ORM 非常优秀，综合评价略强与 SQLAlchemy 』这样的评价没有能说明任何问题，以下是我的见解

在 Python 以及关系型数据库 ORM 中对应的 Django 跟 SQLAlchemy 可谓两个很典型例子。 Django 很明显是从 RoR 里面得到启发，因此很多时候它也很像 RoR ，比如 Django 就是典型的 Active Record,数据库里面的行直接映射成 Model 的实例，并且所有对数据库的操作是直接与实例绑定，例子即为:
New.objects.create(title='sport', author_name='Neo')
对象（实例）不单单封装了数据库表里面的一行（数据）还封装了数据库的操作，以及在这些数据上面有领域逻辑，比如：
User.objects.create_user('john', '[email protected]', 'johnpassword')
Active Record 对象不仅仅有访问数据的一些方法，而且还有领域逻辑（我们实际的业务逻辑），而且领域模型中的数据跟数据库基本吻合

而 SQLAlchemy 的领域模型就不一样， SQLAlchemy 是基于 Data Mapper 设计而成的。 SQLAlchemy 的数据操作是不能直接作用与实例，它是通过一个 proxy(Data Mapper)来维护领域模型（大致上对应 SQLAlchemy 里面我们定义的 Model ）跟数据库表的映射关系，它最大的优点便是数据库表跟领域模型是两个独立的概念，他们之间的关系是解耦的，因此他们可以独立演变，这之后需要做的只不过是我们去更新 Data Mapper 。因此 SQLAlchemy 给我的最大印象就是，它可以实现多态，比如一个 Animal 类可以对应数据库里面的 Dog 跟 Cat 表，以至于一个 Animal 的 cry 方法可以返回"woof"或者"meow"

同时 SQLAlchemy 还有 core 模块去提供高效率的查询（效率可以达到 raw sql 的水平）同时它的查询方式跟 Django 比起来更多样，比如 SQLAlchemy 的 ORM 模块能提供跟以下 SQL 语句对应的查询方式（仅通过一个查询）：
select username, score from users join classmates on users.user_id=classmates.user_id where classmates.age > 20 group by (users.username, MAX(users.score));

我个人是觉得 SQLAlchemy 从功能以及灵活性来说都是源于强于其他 ORM （ python 以及对应关系型数据）。但是它跟 Django 比起来就是它有一个很陡峭的学习曲线，这是它的最大缺点。因此我是建议简单项目或者与 Django 相关的使用 Django ORM ，其他的话，若是你们团队协作，而且会有领域模型跟数据库表演进速度不一致的情况，那么选用 SQLAlchemy 是一个不错的选择。