商业公司都一个样，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 运行，这样就可以做到底层的都是字节码，而上层不变。

PaaS 本身就是 Google 提出的概念，所以你们选他们家的就最好了。根据 Google 的说法，SQL 这样的东西本就不适应云时代。你看看他们的刚开始的版本，想用数据库也就好像是一个 BigTable 能用。分布式数据库又要支持 SQL 很难做的。慢其实正常的，除非单机。

@findbrick 其实如果很简单的程序，可以用 golang 改写，一键编译成对应平台的可执行文件，对于这个，golang 做得还行。如果比较复杂，一定要 Python 的话，那么就用 @wlwood 的方案或者你们上个 CI 服务，最不行你就上个虚拟机吧

是一个脚本还是包括二进制代码？
不过你们有这样的需要我建议你们还是寄希望与跨平台比较良好的语言，一旦 Python 涉及到 C 扩展，你的跨平台就不好做了。

@nullen 原子钟一个例子而已，如果这个例子不合适，那么举 Google 内部的 TPU 吧，这个市面上总没有了。

我就举个反例，google 现在的 spanner，论文已经发了，你去实现试试看。别人有定制的原子钟，你怎么实现？你知道原理又不代表你能实现。
再举个例子，你拿到 redhat 维护的包的源代码也编译不出跟它效率一样的包