各自编程语言的对比

写这个话题风险很大——很容易变成拉踩，然后评论区开始打架。所以先把话说在前面：我不是来排名的，是来记录"我用它们的时候，各是什么手感"。这些感受都来自我自己动手写过的东西，不是看的测评。结论也很朴素：没有最好的语言，只有"在你手上那类问题里更顺手"的语言。

一、先说我不打算干的事

我不打算做三件事。第一，排一个"谁最强"的名次——这件事在抽象的层面做没有意义，同样一门语言写一个自动化脚本和写一个高并发后台，评价完全相反。第二，拿性能基准测试的数字来吓人——那些数字在实验室里成立，但落到我自己手上的问题里，通常不是决定因素。第三，劝你换语言。语言换得越频繁的人，通常做成的事越少。

我要做的是：把每一门语言在我手上的真实分工写清楚，最后告诉你我是怎么选的。

二、一门一门说

Python —— 我的默认选择

手上的问题只要能用它干，我就用它，不怎么想。原因不复杂：写得最快、需要的东西基本都有现成的、三个月后自己还看得懂。

JavaScript / Node —— 界的通用语

它最大的特点是：同一个语言能管前后两头。页面上的交互和数据从哪来的那部分，可以共用一套思路，省掉一次"翻译"。

另外它的事件驱动模型很契合"同时等很多事"的场景——比如同时处理很多个连接，每个都不怎么占计算。但它的坑也很明显：这门语言的历史包袱重，同一件事常常有好几种写法，写惯了 Python 再回来会觉得啰嗦。而且一旦项目变大、依赖变多，维护成本会明显上升。

Go —— 适合"同时干很多事"的活

我对它最深的印象是两句话：编译出来就是一个文件、并发写起来不别扭。

"编译出一个文件"这件事被严重低估了。它意味着部署的复杂度几乎为零——传到机器上、跑起来，就完事了，不用管运行环境、不用管依赖版本。如果你的痛点是"部署老是出问题"，这个特性比任何性能数字都值钱。

代价是写起来没那么"自由"：语法要求严格、写小脚本会觉得繁琐。所以我的用法是：需要长期稳定运行的、要同时扛很多任务的程序，用它；只跑一次的小活，不碰它。

C / C++ —— 需要极致速度的时候才请出来

它给我最直接的感受是"能碰到机器的底"。内存怎么放、数据怎么排，全在你手上。代价也一样直接：手上多了自由，也就多了出错的机会。指针用错、内存没释放，这类问题排查起来花的时间常常超过写代码本身。

我的用法很克制：只在某一个具体环节确实慢、而且这个慢真的影响结果时，才把那一小块单独拿出来用别的语言写，剩下的还是留给舒服的语言。为了 5% 的环节把 95% 的代码重写，是不划算的。

Shell —— 系统层面的胶水

它严格说不太算"编程语言"，但在实际工作里的分量非常重。所有跟系统打交道的活：批量改名、清理、备份、定时执行、看日志、查进程，用它都比写程序短得多——一行命令顶别人几十行代码。

它不适合写复杂逻辑（超过五十行就该换别的），但它是所有其他语言的启动器。我写的 Python 脚本，绝大部分是被一条 shell 命令定时唤起来的。

三、按维度横向看一眼

下面这张打分是我自己的体感，不是客观评测。分数高的地方只代表"在它擅长的场景里"，不代表它全面更强。

把这四组放在一起看，结论就很清楚了：没有一行是同一门语言全占的。Python 在上手和轮子上遥遥领先，在速度和部署上垫底；Go 正好反过来。这就是为什么"哪个最好"这个问题没有答案——它取决于你把哪一列看得更重。

四、我实际是怎么选的

遇到一个新问题，我会先问自己四个问题，答案一出来，语言基本就定了：

1. 这件事跑一次就完了，还是要天天跑？一次性的，怎么快怎么来，命令行或者几十行脚本；要天天跑的，才值得为它考虑结构、日志、错误处理。
2. 它是要长期挂在那，还是用完就关？长期常驻的，优先考虑部署省不省心、崩了能不能自己起来。
3. 慢是因为在等，还是因为真的在算？这个判断最关键。在等（网络、磁盘、对方响应）就换写法；在算且影响了结果，才考虑换方案。
4. 只把那一小块换掉行不行？绝大多数情况下行。这是我最推荐的做法——用舒服的语言搭主体，只在真正的瓶颈处换刀。

五、最后一点想法

语言之间的差异，被讨论得远远超过了它实际的重要性。变量、判断、循环、读写、处理错误——换个语言，这些概念全都在，只是换了身衣服。

所以我给刚上手的人的建议一直是同一句：先把一门用熟，熟到能独立做出完整的小东西，再去碰别的。到那时候你会发现，第二门语言需要的适应期短得惊人——因为真正难的部分（怎么把问题拆清楚）你已经会了，剩下的只是语法替换。