@
reus OK。bash + C是通过binary link还是通过process exec？如果是binary link，那么压根就没有多少bash扩展。如果是通过process exec，那么性能极差。无论哪种，都能说明你所举的bash例子没有任何意义。按照你的定义，pure bash下你几乎啥都做不，别说甩9条街了。
python不调用gevent，就算用raw socket最终也要调glibc的。java也是一样。
不然怎么创建fd？怎么进行网络IO？那么按照你的意思，这个“使用C”的边界到底在哪里？凭啥python通过gevent调用epoll就是调用C，jvm通过glibc调用epoll/select/what ever就不是调用C？
讨论问题，大家首先得在一个公理系统内，不然就是鸡同鸭讲。所以说，你首先得给出一个令人信服的边界。不给出边界，不做出明确的定义，直接做各种无意义的类比，我只能说你是来搅浑水的，当然不要怪我说你没节操了。“没节操”这3个字也没有上升到人身攻击的高度，这只是对你这种做法的吐槽而已。
我给出的判定依据很简单，假设你只会java，我只会python，再来一个只会bash的人。大家都不会C，更不懂得怎么写C extension。在这个前提下谁的解决方案好就是谁好，这个判定依据很合理，也具有实际意义。
你不同意，那么你倒是说个更合理的判定依据呢？还是说你只会一味的说这个方法作弊？
就算是你说什么作弊，那jvm不是在某些benchmark中比C还要快嘛，有什么好怕的呢？
或者按照你这种必须完全得pure code的标准，我是不是可以认为jvm通过jit编译成native code，用native code替换pure code实现也是作弊？
最后，我没有说cpython vm比jvm效率高，我说的是overhead低。而overhead高的原因有很多，光举一个动态强类型对比静态类型的说法没有意义，而且这个问题要说清楚太折腾，都可以另开个话题了。
所以，我对你的吐槽，完全是针对你举的bash那个例子开始的。咱先别急岔话题，先把这个问题说说清楚，OK？