@lolizeppelin

你的回复代表了一部分“迷信”。

Python 有优秀的路径处理库，其他语言能不能有？如果不能有，那说明 python 真的优秀，只有他能做出这么好用的库。
你的说法只能体现一个事实，很多人用 Python 的时候需要处理路径，所以有了这样的库

Python 有 psutil, 没见哪个语言提供了这么方便的进程管理库。
你的说法只能体现一个事实，很多人写 Python 需要手动管理进程。

python 把各种系统调用封装得非常方便,没哪个语言在这方面能这么舒服的。
这个我有话说，python 如果不靠 gevent 这种外挂，封装一下异步调用链试试？当然，现在有 asyncio 可以跟上了。

剩下的我不一一反驳了
当你陷进了一种路径依赖，或者所谓变相的人择原理的时候，python 什么都是香的。
只有跳出这种狭隘环境比对，你才能发现别的语言的好。

@zone10

吐槽我不了解 python 之前请在本帖中查找我不懂 python 的迹象。
不然的话，你也只是跟你吐槽的一样，凭着莫名其妙的印象来吐槽，一点价值都没有。

何止有 Jython， .Net 上也有 python 呢，实际项目中有多少人用你知道吗？
GIL 是 CPython 的锅，那你告诉我 Pypy 现在有没有 GIL ？

吐槽之前请先多了解你要护的。

@2gua

这种东西，C# 什么的，也能直接搞定啊，不就是字典字面量，然后展开再合并而已嘛。
人家还能不创建新对象的情况下完成呢。

@est

我们也没想过一直永远都能靠 python 做这个，但没想到这么早就不行。
考虑到大家都懂点 python，用这个写应该容易理解不犯错，毕竟协调这部分逻辑反倒不容易讲得清。

直到我们发现它抗不住。

@est #95

肯定是采集和统计一起做的，必须和计算任务在同一个节点上，不然协调者本身还要跨网络这样太不可靠。

可能采集的时候 IO 可以效率提高，这部分或许还可以优化，或许上 asyncio 还可以提高性能。
但是既然决定要换掉 python, 再想这个有点迟了。

@est 看清楚，python 只是做报告热点的部分，简单来说思路就是在 UnixDomain socket 里面统计一下（当然这个统计可能运算也很大吧）

引用计数一般不被视为 GC 的手段，最主流的 GC 算法思想是 Mark and Swept，意思是标记垃圾然后清除。
这个过程中不含任何引用计数。

引用计数也无法达到 GC 的效果，因为引用计数无法使相互引用的多个对象引用计数降为 0，因此这些对象也不能正确析构。

@lolizeppelin @est

十几二十个逻辑 CPU 同时抢一个锁恐怕你们没想过这样的数据结构怎么写。
幸好设计上一开始就没考虑过用 python 做这个计算，只是做外围的。
要是遇到 GIL 这样的查询恐怕排完队就天亮了。

可以透露的计算主业务是这样的，一个分布式的 R 树，将查询递归下降到各个不同的子树，这些子树的数据可能在同一个机器上，也可能在集群内另一台机器上。每个节点要主动分担查询热区的压力。

Python 的进程只是报告一下查询热区在哪里，但即使是这样，这个报告延迟还是太大了。

@est 你的思路就是我们的解决办法之一，然而我们已决定逐步扔掉 python 的部分，用更高性能的 Go 或者 Rust 重写来替代，这又是一场腥风血雨。

这就是吐槽 GIL 的原因，没想到它能撑的时间这么短。

@mumbler Powershell 怎么样？

@est #59

反正不是锁导致线程等待。IO 频率这么低，一个线程和内核交换数据就够了。
倒是 GIL 这种东西明显造成非 python 进程与 python 进程间数据交换瓶颈。

那些说 Python 开发快的，我估计都是业务量不大，连原型都跑不垮的穷鬼公司吧。