@JasonLaw 典型的 X 问题，Y 问法，得到 Z 的答案。
你想想你为什么需要用多线程？你不就想节省内存，多跑几个实例嘛。就 chromium 那个架构，你就不用想这回事。而且用 pyppeteer 试试吧。

葛兰素史克出的辅舒良

@des 直接用 PyPy，不用等

@sharpy 你自己实现的，人家可不一定会用。这是语言生态的的争论。社区不会一定会用非标准库的东西。

@gggxxxx 其实是你觉得变了，毕竟人多了，宣发手段也变多了。这个市场还是没有什么太大的变化，你的产品好，当然可以直接收费。
国外一大堆还是直接收费的，当然还是要有试用版的。
vmware 的软件都是闭源的，搞虚拟化的还是很多用 vmware 。比最大的开源社区平台 github，那就是闭源的，一样很多人去用。
还是产品的好坏起关键作用。是不是开源，其实有时候真的没有那么重要。最终用户没有多少人会编程。会编程的也不会多少人会去从 0 构建产品

你同步 IO 的操作，那么就放在线程池 /进程池里面跑，跑完返回结果就可以了。标准库里面是有相关的辅助函数的，你去看看 asyncio 里面的文档。
tornado 是兼容 asyncio 的，你直接用就好了

numpy 在实际会用到 blas 的相关实现。很多时候哪怕你认为是读取的操作，实际上可能是当矩阵变换的操作。会有对应的加速的。一般人写不出那样高效的代码。如果你觉得效率没啥所谓，其实自己用 C 写一个也可以。关键还是看你实际的需求

自建也是托管啊，难道服务器放办公室么？那不是扯淡嘛，网络，电源都很容易断的。数据中心可是有整个变电站在旁边专供它，还有一大堆 UPS 。一般人哪有这个资本搞这些啊。
如果你能忍受生产环境下线时间达到 8 小时的话，那么自建问题也不大。问题还是你的生产环境能忍受多大的故障率？不是说硬件的钱才是钱。很多时候服务也是分级别的。专线是有 QoS 的，跟你 frp 是不一样的。人家电信运营商网络策略可以随便给一般用户做限流，反正一般民用的网络是没有 QoS 一说，你看到的只有带宽。
研发以及测试环境可以用本地的，但是生产还是要上数据中心的。最次也去托管吧。生产环境记得去搞专线，国内电信运营商对 udp 限流都属于正常操作。

因为作者没有开通商业咨询服务，有问题要提高服务的优先级可以啊，付钱就可以了。好比微软的付费技术支持，一张高优先级的工单 1000 美元这样就差不多。只要他不愿意给钱，那么就爱用不用。可以直接站在道德高地怼他

还有人用 GoDaddy，hacker news 上面都不知道发了多少次了，你只要搜一下域名，GoDaddy 就自动将它买下来，你只能花大价钱从它手里接盘。就这样的破玩意还推荐？
namecheap, name.com, gandi 有什么不好？

不改程序几乎是不可能的，能改程序的话，无非就是通讯的问题。那么就会变成 rpc 的选择
你可以选择 grpc, brpc 等工具建立通讯。也可以用 mysql, redis 等数据库进行通讯，也可以用 rabbitmq 之类的建立通讯。方法太多

@HashV2 你的 field1, field2 有 null 值么？要你指定的哦，只是 order by 是不应该出现你说的情况的。如果可以的话，你发一下 SQL

另外 uuid 类型一般是有优化的，不会造成很大的影响。记得不要存成字符型就可以了，存成字符型就没救

@icyalala 绝大多数开发都用 ubuntu，是这样的啦。很多人又不是运维人员。而且就算是用了 SUSE 系，人家也不会大吹。所以热度下降是对的了。

你的项目切换重新做索引不是很正常的吗？谁知道你的环境里面装了什么库，不扫描怎么知道呢？
要说避免，那么你不换就可以了，为什么需要切换好几个环境进行开发？

假如你说的是你引用的那个情况，那么我可以告诉你，pg 的实现才是对的，引入了 window 函数。mysql 那种就是扯淡实现，一般出现在瞎用 order by 的情况下。SQL 严谨一点的 pg，你压根就不能实现查询。mysql 居然随机给你一个结果。

1. 改成 RPC，微服务改造
2. 修改代码，改成一样的版本

没记错的话，微信是参考微软的 Exchange ActiveSync 。用 mqtt 硬套不了。同时最开始的那版好像是基于 xmpp 的