后端业务很多是 Python 写的，基本每个微服务代码量都至少是几万行的规模。各个项目加起来没有百万行也至少是几十万行的规模。现在基本上 java，go，Python 都有。

有同事比较痛恨动态语言的，觉得维护起来心累。之前有学术研究专门统计过github上不同语言项目的出错率，结论就是静态语言确实更不易出错，维护性更好。动态语言就需要良好的工程实践来控制，不过灵活性更高，表达能力更强。如果真的是超大型单体项目，静态语言确实是个更优的选择，这个是有统计结果作为支撑的。

脚本语言是在互联网时代才逐渐流行的，并且互联网公司很少用单体架构了，一个服务代码量过大对于项目维护，开发，部署，上线都是灾难，很多都是微服务架构了。微服务架构下很多语言都能胜任，几乎都有商业项目的成功案例，甚至很多动态语言快速构建原型反而更有优势，即使将来遇到了瓶颈重构一个服务也不会太难。

下边是一些知名Python 项目的代码量统计，目前最大的Python 项目应该是openstack了，达到了百万行，不过大部分大项目最多也就是几十万行。如果是商业项目，目前不太可能出现一个项目百万行的情况。国内目前很多用Python 的还是中小公司，只可能有大的服务，大的网站，不太可能出现一个超大的单体项目。如果项目组的人员不排斥写Python ，Python 是可以用在很多项目上的，并且在爬虫，网站，数据分析等领域Python 都有比较成熟的解决方案，一开始真的没必要过于纠结技术选型，可能工程控制，代码质量反而比较重要。

易用、灵活、高效，一门编程语言最多只能同时拥有两项。

易用包括：

1. 简洁，易读、易理解、易写；

2. 一致性好，易协作，易接手维护；

3. 基本构造紧凑；

4. 尽可能自包含，拥有丰富的类库和软件包支持；

5. 可移植，对执行环境的假定越少越好；

6. 从编写到执行，整个过程涉及的工具越少越好，程序易部署；

7. 手册可随手取用。

灵活包括：

1. 伸缩性好，删除依赖性与加入依赖性一样简单；

2. 允许在不同层次上抽象（含DSL）；

3. 支持多种编程范式；

4. 尽可能适用于更多的领域；

5. 可定制语言子集（方言）；

6. 可编译执行，也可解释执行。

高效包括：

1. 编写快，越快越好（考虑工具支持与纯手写）；

2. 编译快，越快越好；

3. 除错快，越快越好；

4. 执行快，越快越好。

还有一些特性没有罗列出来。仔细考虑一下，上述各特性不乏相互对立的，如何取得平衡，完全视应用环境而定。这些特性考量将与设计哲学相互影响，最终决定一门编程语言的编写风格与使用方式。

但终究，一门编程语言被设计出来的主要目的，是在成本最小化的基础上，尽可能好地解决某些问题。

另外，不从架构角度考虑开发与运维、用户操作的关系，做出来的东西必然到外都是坑，且很难持续。不要随便看不起一门编程语言，它被发明出来必然有其用处。在恰当的时机用适当的语言解决正确的问题比什么都重要。

写过几年Python，也写过几年CPP，写过几年CS，Python做大项目没什么问题，不会比其它主流语言更差，项目的可控规模多大，主要还是取决于人，不是语言——语言当然有差别，但是没有宣传的那么大。至于开发工具的问题，高水平的开发人员根本不会依赖开发工具。而且，Python本身不是那种非常依赖代码补全等功能的技术，习惯的组合是emacs+ipython+python-mode，用doctesting做TDD，效率很高。最近一段用sublime text比较多，也没觉得离开习惯的环境就做不下去。

至于错误在运行时，这就看自动化测试的水平了。Python项目出现的bug不会比CPP或Java更高。

如果用不好，什么都是烂语言。这是个相当廉价的态度。

用 Boost 去做实际开发？没被编译器坑过的人是幸福的。

能用 std:: 的地方用 C Style 的轮子？没被 std::string 效率问题坑过的人是幸福的。

Python 超过 1k 行就是灾难？这些对语法正确性全靠（即时）编译提示错误的人写什么 1k 行的代码啊。最好的软件工程工具都是语言无关的：Unit testing，design by contract。除了很少的特殊语言（Eiffel，AspectJ），基本都是靠库和程序员手工实践的。

一个公司能像 Google 一样招人，他们用什么语言都可以。如果不能，趁早放弃 C++，修不盈新手挖的坑，扶不正老人搭的庙。

至于性能问题……没有到 Google 这个尺度上，性能问题从不需要从全局方面去解决。找到热点，用合适的工具局部替换，这才是工程上有可行性的方案。何况 Python 是出名的易于用 C 扩展的语言。

Perl, Python, Go，甚至算上 Java……这些语言的问题都是，他们从来不是不可被替换的。他们都在解决非常具体的问题，因此当有一个新的语言在当前语言框架之外解决了一个新的具体问题时候，旧语言就会损失一批用户。Go 的 coroutine，Python 的语法清晰和简单，Perl 的字符串处理效率和随时运行，Java 的库和 GC，从左往右就是这么一个后浪推前浪的关系而已。在合适的地方用合适的工具解决正确的问题是每个程序员和架构师应该会去做的事情。

1 性能有那么重要吗？

现在好像除了超大型互联网公司需要静态语言来省电以外，没有听说过多少因为语言速度慢而出现的软件问题。何况现在慢的程序，以后未必就慢了。可是程序员的速度，可是一直很难提起来。没有银弹啊。

2 程序规模变大以后，真的那么需要编译期的静态检查来排错吗？

无论多么严格的检查都无法阻止程序员写出垃圾来。C的检查比C++弱，但是它在TIOBE上排得比C++要靠前。里奇相信程序员能够做好自己的事情所以没有做出过多的假定，C++看起来严格遵守了很多编程范式，其实过于复杂，直到今天，C++的编译器也不能明确地解决它最复杂的内存泄露问题，这个检查有等于没有。

没有静态编译而扩展成大型工程，请看PHP。请看RoR。更不用说保罗格兰汉姆以前用Lisp曾经开过一个作坊似的公司做出了世界第一流的大型软件。这就是程序良好的风格比什么都重要的一个好例子。动态语言看起来抛弃了静态的类型检查，但是得到了灵活的类型机制，有得有失，在现在看来，是一个很好的趋势。用过动态语言再回去看某些静态类型语言，看多了眼睛流血，写多了手流血。

3 语言一定要依赖于开发工具吗？

不知道真正的语言开发工具指的是什么。事实上除了PHP，现在各大脚本语言的开发工具都只是半斤八两，Python还是其中发展最快的了。觉得好的语言并不应该依赖于技术体系，现在MIT里还是朝圣一样使用Lisp和emacs。emacs很好排错吗？emacs很方便部署吗？emacs很方便做性能基准测试吗？这会影响到Lisp这门语言烂不烂吗？

C++倒是什么工具都有，这让它变好了吗？ 工具其实都在其次，一切慢慢都会好起来的。

每一门语言的设计，都有它的权衡。到底它是设计者怎样的愿景，其实像我这样的低手是很难搞明白的。但是如果它让学生们第一印象很好，那就是一门很棒的语言，绝不会烂。

说两个就近的题外话：

1 好奇号宇宙飞船的两百五十万行的代码，大部分都是用Python生成C的方式写出来的。不知道这算不算一个超过十万行的项目？

2 MIT的计算机第一门课一直在灌输两个道理：计算机程序是写给人看的，恰好能够运行。软件设计其实就是对于抽象复杂度的控制。这两个观念完全与性能、静态检查和开发工具无关。这门课许多年一直用scheme教，前两年突然换Python了。