@lxiange
显然事实就是这样，但是有限并不是因为 32bit 的限制,有限是因为现实资源有限。
我是没想到这个梗居然还可以佐证你的观点。

@q397064399 其实 GC 的实现还是相当公开的， openjdk 里面各种各样的 GC 都有算法论文，以及代码都是公开的，想怎么调就怎么调。
还有一个就是 stop the world 其实也是可以避免的， http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf 这篇论文就有说 azul 是如何实现一个 GC ，并将卡顿控制在 10ms 之内，也有金融公司用了他们 JVM 。

@rogerchen 那样不是可以定义一个数组来表示 2^32 位吗？当然所有的四则运算都要重新定义了，其实就是一个基于字符串存储的运算模型

google 的记得是在香港的节点，延迟是很低，但是费用也高到爆炸

@rogerchen 这个其实也不一定哦，用定义一个数据结构不就可以解决这个问题吗？记得 K&R 里面就有写高精度数值的计算方式。简单的比喻就是像算盘一样，不够位拼一个啊。
不过既然是梗那就算了。

不就备胎的故事吗？感觉就是标题强行加个程序员，其实内容跟程序员一点都没关系。

不可以设置黑名单吗

@murmur 不是 C++吗？看他们招 C++哦

这个不就是二分法求解吗？牛顿迭代法迭代的次数可以更少，但是记得是不能根据任意的 elision 值来求值的。

页面居然是 gwt 写的， Java 程序猿恐成最大赢家

想省钱的话，应该是本地编译以及打包好再上传到服务器。

长连接，慢相应，高并发

@julyclyde 是加-B 吗？

broker 请尽量使用 rabbitmq ， redis 有丢任务的风险， rabbitmq 跟 redis 虽然都是官方支持，但是显然是 rabbitmq 的支持更好，而且 amqp 协议在协议层使得 Broker 可以感知消息消费的情况。当你们上 celery 的时候，请尽量使用 rabbitmq ，那会少很多坑，而且各种监控也比较完善

Celery Beat 不能跟 gevent 类型额 worker 同时使用

说 ORM 影响效率，正常来说都不在转义 SQL 这里，更多的是反射啊，类型转换这些地方。说现在的 ORM 慢，何不先做一下 profile ？以及编写简单的单元测试测试一下。反正模拟一下简单的使用场景又不用一两个小时

@seanlook 我的意思是， DDL 变更是放在一个独立的又运维人员维护的版本库里面，开发人员又没有库的合并权限。开发人员可以提 merge request

数据库变更不进版本库？版本库又不是仅仅开发能用