云不是有一个超额停机吗？

@nannanziyu 所以我觉得作者就很有礼貌跟素养了，跟这样的 Troll 说那么多没用，他若是像 RMS 一样我倒是敬佩他，可惜他这样的人也就说说而已。跳梁小丑罢了。

@Eyon 你若是要深挖这个，也可以搜索高级函数以及柯里化(currying)

每个人都有每个人的自由，正如作者在上面写道

>let's wait and see how we will be fucked.

商业公司都一个样，Google 不说别的，就那三篇论文里面的 BigTable, GFS, MapReduce 又何曾开源？ Gnu Hurd 都搞多少年了，还不是纯粹的开源力量少没做出来。
闭源完全是合理的，哪怕现在闭源也是一个很合理的存在。不说别的，多少公司内部所谓的大数据处理平台能跟 Bing 或者 Google 内部的分布式数据处理平台比？开源只是一个新的公关手段而已，说得好像真的开源了就真的可以拥有自由一样，现实点，开源长达 10 多年的 openssl，还不是有心脏滴血漏洞，这还是一个被大众天天使用，每时每刻都使用的库呢？有多少人做贡献了？这样所谓的自由只是聊以自慰罢了。

说自由，多少人跟做到跟 RMS 一样？
如果因为微软收购 Github 就要离开的人，我敢说，他们应该在 Github 上面不占大多数，他们也不能代表什么。他们根本就不是主流，他们的影响力仅仅是 Github 的极少一部分，这样一些人，无论去哪里问题都不大，青山依旧绿水长流。

@omg21 现在写一个没什么显示问题的浏览器，难度直逼操作系统。君不见 Mozilla 也花了几年才部分重构 Firefox ？ Google 那么厉害也要基于 Webkit 开始，虽然他们现在是改剩不多了。
这个市场以前有 5 家，现在就只剩下 4 个玩家了。

@Clarke
https://azure.microsoft.com/en-us/pricing/details/visual-studio-team-services/
https://cloud.google.com/source-repositories/
https://aws.amazon.com/cn/codecommit/

leetcode，但是看到自己写的程序运行效率那么低，真不爽

@qoras 不可能，因为 CPython 里面所有的对象都对应底层 C 语言级别 PyObject 结构体，每个对象都有一个引用计数，不用 GIL 没法保证引用计数的变动线程安全。
如果改动的话，Java 就是一个很好的例子，大锁改成细颗粒锁，外加 concurrent 包，同时啊，引用计数应该改成 tracing GC。引用计数在现在的技术下不比 tracing gc 优秀

颗粒度不一样，因为如果去掉 GIL 相当于现在的 Python 里面的每一个操作都是不安全的，哪怕你是一个简单的加法运算，因为加法运行也可能变动引用计数。天知道这里面有多少依赖 CPython 实现的。
还有就是 GvR 要求去掉 GIL 不能减慢单线程性能，要兼容性就必须上细颗粒锁，锁多了性能肯定会下降，这才是为什么 CPython 的 GIL 不好去掉的缘故

@fancyhan 哎时代不同了，而且现在真要上 PaaS 平台，你去用阿里云搭一个 k8 集群也行。他们内部太多东西没有开出来，连付费都没办法，普通人真难使用他们的平台。我现在宁愿去阿里云搭一个，毕竟可控性强太多了，绑死在他们那边从商业上就不行。

@fancyhan 当然不是，就是玩得比较早，记得当年 SAE 也是毛病一堆，不过你看他们的收费就知道。适合他们平台的特性收费显然便宜很多。如果你是一定需要 SQL 的支持，那么最好还是不要轻易上 PaaS，因为数据库的伸缩性都很差劲，跟 PaaS 那种可以轻松伸缩的特性不相容。所以为什么 Google 内部开始是提倡用 BigTable，因为 BigTable 伸缩性强。至于 Facebook 这些也是用基于 BigTable 论文的 Cassandra 比较多。
如果偏传统技术的，还是先上 IaaS，这样用起来会比较爽。这个也是为什么各大公司的容器化都是要一大堆人去推进的，因为他们的基础服务根本就不具伸缩性。

根据百度的服务来看，他们的技术还是很厉害的，记得当年还自研一套跟 Hadoop 抗衡的大数据平台，可惜办公室政治。不过说起来还是千万要注意你的程序是不是跟平台匹配，要不然换 Heroku 或者 GAE 也差不多。很有可能会以为业务发展你的数据库撑不住。而在他们这些平台上，你连调优很可能都做不到。

没法保证线程安全，想安全，老实上锁

@fancyhan 跟 BigTable 比起来不行，CloudSQL 都是 google 发现程序员都不会搞事务，还有离开 SQL 就不懂写程序。所以才出 F1/Spanner，然后搞出 CloudSQL。你测一下事务，涉及跨机器的就慢了。这个没办法，国内的 TiDB 也是这样。
我只是说这些分布式 SQL 慢可以理解的，如果真要上他们这些 PaaS 平台，最好还是根据他们的特性来写程序。好比你不能要求在支持 AVX512 指令集的矩阵运算程序去到 arm 平台上跑得一样快

@est 依赖特定实现的行为都是异端，哎~，这样的没法说。

@est 其实按 GraalVM 的思路是可以的，Python 实际运行的是 GraalVM 的字节码，至于 C 扩展，编译成 LLVM IR，也是又 GraalVM 运行，这样就可以做到底层的都是字节码，而上层不变。