Robert Love, Google Software Engineer and Manager on Web Search.
Upvoted by Kah Seng Tay, I was the Head TA for a class taught in Java at MIT. I used…
Robert has 10+ answers in Google Engineering.
Man, I cannot imagine writing let alone maintaining a large software stack in Python. We use C++, Go, and Java for production software systems, with Python employed for scripting, testing, and tooling.
There are a bunch of reasons for the primacy of C++ and Java:
- Familiarity. Early Googlers were well-versed in C++.
- Performance. Java can be faster than Python; C++ can be faster than Java.
- Tooling.
Tools for debugging, profiling, and so on are significantly better for
Java than Python. Even C++ is easier to debug and understand in large
systems. - Concurrency. As you can imagine, Google systems are
highly parallelized and many are highly threaded. Threading in Python is
an unmitigated disaster. The global interpreter lock (GIL) is a giant
pain in the ass. - Lack of need for the prototyping prowess of
Python. One commonly-cited strength of Python is that it is easier to
rapidly prototype small systems in Python than Java and (to an even
greater extent) C++. At Google, however, this benefit isn‘t all that
appealing: We have a lot of powerful frameworks that make prototyping or
extending existing systems easy. Folks tend to prototype by gluing a
hack into an existing server rather than build an entirely new
distributed system.
Don‘t get me wrong, in the war of Perl
versus Python, I come down on the side of Python. But I would never use
it to build a production, scalable, mission critical, performant
system—particularly one someone else may need to understand some day
long in the future.
太多硬伤和臆想，懒得批。只说“代码超过 10w 以后你就别想用 python 开发了”这一句，2012年4月豆瓣主站项目代码行数就近50万行了，可我们还在用 python 开发。
我写过几年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，从左往右就是这么一个后浪推前浪的关系而已。在合适的地方用合适的工具解决正确的问题是每个程序员和架构师应该会去做的事情。
在一门语言里找槽点很容易，不找槽点开口就喷更容易。乱喷一时爽，过一两年回头看看自己说过的话，还没被自己的幼稚笑死的人，估计也没有进步的余地了。
没有用Python写过一行生产代码，现在用Python写快排还是二把刀的水平。
本来我根本不适合回答这个问题的。不过那群组里的讨论，涉及到了很多语言的历史。我觉得可以从其他语言的角度来讲讲。
早期的语言，没有那么强大的编译器，不足以做出那么多的静态检查，所以从汇编到高级语言这一步，有大量的黑客工程师下了苦功来制造工具链。他们针对高级语言的种种遐想，实际上是他们受尽了之前的语言的苦楚的产物。
肯汤普森最早趁老婆回娘家的时候写Unix原型的时候用的是汇编，对他来说当然绰绰有余，但是汇编的抽象能力不足，于是他用发明的B语言又重写了一遍。在这一步，B语言胜过汇编的就是它的优美。
但是B语言是动态语言，性能很差，于是里奇加入以后，在它的基础上再发明了C语言，性能得到了很大的提升。在这一步，又是对性能考量起了很大的作用。
后来本贾尼因为剑桥念书的时候用动态语言BCPL毛骨悚然的经验，在强类型弱检查的C语言基础上发明了C++。他似乎认为足够强的语法检查就足以应付软件工程的复杂度。事实证明他错了，在大型项目上C++是个烂语言的呼声比Python不知道早了多少年。
后来有了Java。它并不是C++加上些语法糖的产物，这个我就不说了。Java能胜过C++而大行其道，就是因为它语法足够优美。事实就是，如果我们不写战斗机的火控系统，不写操作系统，我们为什么要那么在乎性能？
Java火了以后，之前的Python和之后的Ruby都渐次火了起来，Web时代到来，PHP也火了起来，后来JavaScript也火了起来。这些语
言都不那么看重性能，似乎现在就是一个语法优美的时代了。因为现在程序员的时间已经比机器的时间要贵重了。
那么我们来探讨几个问题：
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了。
今天在InfoQ看到一篇文章”Visual Studio Python工具和Node.js工具介绍“，PTVS的开发人员说”Python本来就已经被很多工业领域所使用。Reddit、Youtube、 Dropbox等流行的网站都广泛地使用了这门语言。有很多财富500强的企业也使用了Python。某个主要金融机构的一个项目有3000名开发人员和 超过1600万行Python代码，这是我们了解到的最大的Python项目之一。“
一次在Quora上有人问算法导论的作者，你们写代码最喜欢用哪种语言啊，人家说“我首选python”。
我发现python已经渐渐地
成为了机器学习，自然语言处理，机器视觉，数据分析方面研究的首选语言了，再往后，python会不会在更大程度上侵蚀matlab和
mathematica的阵营，成为通用数学建模的首选语言，从而在更加广大的天地中发挥它的简单与优雅之天性，也未可知哦。
你能想象某
一天，某研究团队率先用python写出了对全人类幸福和进步有意义的代码（数学、物理、生物方面的模型）。至少我相信python的优雅简洁是让它最有
希望做到这一点的，因为十几年前Perl
对人类基因组计划已经做了类似的事情；似乎在好奇号火星车上python也已经做到了（推动科学的前进）。因为比起人类的这些成就，那些成天讨论
C++，Java，PHP，python，ruby孰优孰劣的人，成天讨论库、类型的强弱，能做多少个connect，性能差多少个百分比，缩进好不好
看，实在渺小无意义啊。
How Perl saved human genome
把另一个回答转一部分过来：你如何看待王垠的《什么是“脚本语言”》？
根据这些年用过的编程语言，我总结出一条判断语言是否值得学习、使用的指导原则：
易用、灵活、高效，一门编程语言最多只能同时拥有两项。
易用 包括：
1. 简洁，易读、易理解、易写；
2. 一致性好，易协作，易接手维护；
3. 基本构造紧凑；
4. 尽可能自包含，拥有丰富的类库和软件包支持；
5. 可移植，对执行环境的假定越少越好；
6. 从编写到执行，整个过程涉及的工具越少越好，程序易部署；
7. 手册可随手取用。
灵活 包括：
1. 伸缩性好，删除依赖性与加入依赖性一样简单；
2. 允许在不同层次上抽象（含DSL）；
3. 支持多种编程范式；
4. 尽可能适用于更多的领域；
5. 可定制语言子集（方言）；
6. 可编译执行，也可解释执行。
高效 包括：
1. 编写快，越快越好（考虑工具支持与纯手写）；
2. 编译快，越快越好；
3. 除错快，越快越好；
4. 执行快，越快越好。
还有一些特性没有罗列出来。
仔细考虑一下，上述各特性不乏相互对立的，如何取得平衡，完全视应用环境而定。
这些特性考量将与设计哲学相互影响，最终决定一门编程语言的编写风格与使用方式。
但终究，一门编程语言被设计出来的主要目的，是在成本最小化的基础上，尽可能好地解决某些问题。
另外，不从架构角度考虑开发与运维、用户操作的关系，做出来的东西必然到外都是坑，且很难持续。
不要随便看不起一门编程语言，它被发明出来必然有其用处。
在恰当的时机用适当的语言解决正确的问题比什么都重要。
好奇号火星车的开发语言大部分就是 python 只不过执行时是C
好奇号火星漫游车使用的是BAE制造的
RAD750处理器，运行的是Wind River
Systems开发的嵌入式实时操作系统VxWorks。根据开发者的幻灯片介绍(PDF)，好奇号代码共250万行，程序语言是C，多是用Python
脚本自动生成，NASA
JPL共有30名程序员参与开发，测试团队超过10人，超过一百万行代码是手写。程序包括150个独立模块，每个模块执行不同的功能，高度耦合的模块组合
成组件。
如果去编写一个很精密的东西，没有一个严谨的类型系统是很难想象的。
我们的SQL优化器，核心代码大概只有1w行左右，全部用C++和Java编写。其涉及到的各种精巧算法，如果用Python维护起来是很痛苦的。
附上一篇介绍PostgreSQL optimizer论文（http://db.cs.berkeley.edu/papers/UCB-MS-zfong.pdf）中的一段话：
Query optimization requires a great deal of element manipulation. The optimizer must separate,
modify, and regroup elements within a query’s target list and qualification to create new components for
individual nodes in the plan tree. A programming language like LISP is well-suited for this type of processing
because the language contains functions and data structures specifically designed for object manipulation
tasks. Consequently, for ease of implementation, we chose to write the POSTGRES query
optimizer in LISP.
可见语言的选择多么重要
应该这么说，在大型项目上，Python社区相对于Java、C/C++等语言，缺乏足够的经验和范例。而Python本身也有一定的缺陷，这一点在大型项目开发时会被放大。
但
是大型项目，往往都不是一两种语言开发而成的。一般来说C/C++、Java是最常用的，如果是B/S架构的项目，那么JavaScript必不可少。如
果脚本写的非常复杂，可能会用Perl或Python来代替Shell。如果是运行在Windows平台下，又是C/S架构，也可能会加入C#。
另外，不是代码行数多就叫大型项目，这个项目得要有一定的技术含量。
最终能写上千万行项目、或者要命的项目（譬如说卫星和战斗机，一个下来也要几百万行的）的语言，都是那些能做、并且有人投入精力去做其静态分析工具的语言，譬如C/C++，C#和Java。所以说python肯定是没戏的（这跟他的性能没有关系）。说实话，10万行代码一点都不算多，就算是充满了各种DSL、奇怪算法和设计模式的www.gaclib.net（刚好10万行），我至今仍然能够把细节都装在脑子里。我觉得python的上限应该取决于那个人自己的水平，不过大约也就在几十万行上下了。
随着传统静态语言对自动类型推导和函数式写法的支持，我的确认为动态语言是要被淘汰的。
当然我在扯淡里王垠对语言有很多思考，是值得参考的。
包
括很多特定目的的语言也逐步不再需要，比如awk，ant。比如现在的build工具一般都会是全功能的通用语言，scala的，rust的，具体我已经
忘了，但随着比如java，scala这些对lambda的支持，通用语言配合lib已经可以达到声明式语言，动态语言，函数式语言的简洁了。
我们需要静态类型系统来帮助我们，因为我们大脑能力有限，我们是谦卑的程序员。
用python的好处就是这位兄弟还在跟你讲python怎么不好的时候 你的1k行的代码都快写完了..
语言之争从来都是毫无意义，好的设计架构才是最重要的
代码行数和大型项目有什么关系？我认为python不太适合大型互联网应用，当然首先说豆瓣是一个特列，他们有太多的牛人，说真的，把这群牛人聚集起来用什么语言开发都行，只要他们愿意。
原因有几点：
1.
python没有多线程，无法利用多核，也更别提强大的多线程包了。我之前想通过python脚本来测试一个java
RPC框架的最大并发能力，却没有办法，因为单个python脚本根本无法压榨机器。而java得益于大神DougLea开发concureent包，提
供了各种多线程开发中需要使用各种利器：Executor，Atomic，Lock, BlockingQueue等。
2. python没有一个强大，高性能的web应用服务器。gunicorn和uwsgi已经算python最好的web应用服务器了，但性能真的差强人意。
3. python缺乏一系列诊断工具。jvm提供的jstack,jstat,btrace真是太强大了，而python...提一个基本需求吧：谁知道如何实时dump线上运行的python thread stack？
4. python没有一款合适的web开源框架。web.py太简单，基本等于从零开始开发，表单验证，middleware,csrf啥都没有，只有一个url mapping。而django的性能太差，又给你一堆没用的东西。
5. 有人会反驳说python没有多线程，但有纤程（协程）啊！是的，但python如果要使用gevent，有太多的坑要踩。你除了自己的代码需要考虑纤程，还要考虑mysql,mongoDB,redis,memcached等客户端。
6.
python大部分开源库的connection没有pool，或者是这些conection
pool不能很好的和gevent一起工作，这在大型互联网开发中是很恐怖的。原因是，很多conection
pool是通过threadlocal实现的(参考python memcached的源代码（https://pypi.python.org/pypi/python-memcached/）)，而纤程的threadlocal实现有点奇葩。
python是一门好语言，但个人觉得python更适合在自然语言处理，机器学习，火星车开发，探月工程等单机系统。不适合需要支撑大流量访问，业务快速发展，团队成员都是屌丝没有豆瓣大神的互联网应用。
虽然在TL组的另一个帖里回复过这位microcai，既然在这里看到就再说一下吧。
在那个帖里，他说道：
我给出了详细的 python 为啥很烂的解释
https://avlog.avplayer.org/3597082/python%E6%98%AF%E4%B8%AA%E7%83%82%E8%AF%AD%E8%A8%80.html
我可不是那种简单的给打个标签 缺乏根据在那里胡扯 的那种人.
谁要是不同意可以逐条反驳.
但
是说实话，他这段恰恰就是“缺乏根据在那里胡扯”，而且是从开始提到python就扯——比如解释器比编译器（他还给说成了汇编）简单，除了C++那种变
态级别的编译器，python的解释器不比其它编译器简单多少。另外，python也需要编译为pyc，除非说.net/java也是解释语言，何况就算
是编译成目标代码，也有cython这种间接方式，或是pypy这种动态方式。
当然我不会真的逐条反驳这么浪费时间的，上面这条就足够说明他的问题了。
回到楼主的问题上：python是否不适合大型项目？
成功的例子参见 @洪强宁 等人的答案。
事
实上项目管理的根本问题是对人的管理。java之所以适合做大项目，很大原因在于比较容易找到一帮水平差不多的人，并且管理起来也比较容易。python
的优点是易学，虽然找一大帮人不容易，但培养起来比较快，规划得当问题也不太大。但是C++就不同了，找一帮会C++的人不难，但是水平参差不齐，如顶楼匿名人士所说“你修不盈新手挖的坑，扶不正老人搭的庙”，就算是找到一帮C++高手，还各有各的习惯和爱好。至少python还有pythonic这条阳关道。
不要闹，看这里 (⊙o⊙) --> http://en.wikipedia.org/wiki/List_of_Python_software#Commercial_uses
当然，不得不承认，纯用Python不是一个好主意。胶水语言就应该起到胶水的作用。建立结构清晰，易于控制的框架。内部结合别的语言实现（不得不说，Python和别的语言结合很棒。。当然，我只知道C的情况）。
其次，很多时候，项目的问题不是Python造成的。 Disqus的C同志曾在PyCon2011讲过一个lecture，应该能对lz有所帮助。
传送门在此：Watch PyCon 2011: Disqus: Serving 400 million people with Python
1，世界上没有垃圾的语言，只有垃圾的程序员。
2，绝大多数项目的瓶颈根本不再工具本身，而在于使用工具的人。
3，绝大多数程序员对语言的理解深度与高度根本没资格攻击。
不说python,说JAVA,其实JAVA优(平)秀(庸)的原因,但从语言历史上来说,个人觉得JCP是个很重要的原因,JCP从较长远的眼光,以步履薄冰的方式保证JAVA的兼容性和大一统,避免重蹈C++分裂和碎片的格局,so....python....
写一个☆‘Hello,☆world!’, 用
50年前的☆Fortran,
40年前的☆C,
30年前的☆C++,
20年前的☆Java, 和
10年前的☆Python,
现在☆哪个
还可以☆编译☆运行？”
又诗为证：
“Python,
胶水语言，
在大项目中，
注定☆打酱油。
酱油☆豆瓣，
豆瓣☆酱油，
一对☆好朋友。”
——
严肃地说，Python 是个有用的东西，然而它的创始人朝三暮四，一会儿忽悠大伙儿用别用 open, 用 file，一会儿又把 file
给废了。一会儿忽悠大伙儿别用 range, 用 xrange, 一会儿又把 range 给废了，把 xrange 也给废了。如此等等。至于给
print 加重定向这种先有个楼房又搭个窝棚，然后号召大家去住窝棚的脑抽设计，危害性算小的，我就不说了。
写大项目主要是逻辑的管理，和人的管理能力，与语言没关，有些语言强制加了管理能力，就省了很多管理的规划。举个浅显的例子。
汇编语言是最没管理能力的，甚至变量就是内存和寄存器
C语言有点管理能力，至少分了全局，局部，函数，函数体内变量隔离
汇编就不说了，C语言对于没经验的几个人来说很难写大型程序，
但是简单的规划一下就可以写了
例如，每个变量都前缀个人的名字，int tom_var; char jerry_var;float xx_var;
然后如果需要共用的，就写 int public_var;
函数同样处理，这是个非常好的技巧。。。。。。。
但是这种技巧一直被别有用心的公司讽刺
于是出现了C++;c++ 其实把名字换成了命名空间，然后把一些函数加了class头，然后引入了面向对象的东西。但是class里面加了太多的歧义和难于理解。
于是又出现了，java ，强制用包，类
java算是编译语言走到的极点，算软件工程的产物，加了太多管理和约束的东西
导致写代码又罗嗦，又麻烦。适合大工程，但是效率很低（开发效率）
python出现了，更接近人的语言，高度的逻辑化，用python 基本上比java的逻辑减少了3倍。
大项目本质上是大逻辑的管理，python从理论上说能写比java大3倍的项目
一个语言只要具备了，函数，类，模块，包就是一个具有良好管理能力的语言。
如果你觉得什么语言写不了大程序，仔细思考一下你的逻辑管理能力
或许 c是个好的锻炼方式，如果没有类，每个文件变量会冲突，你该如何解决呢！
分割线----------------------------------------分割线
吐槽。。。。加班中。。。写代码。。。。。随便看到，忍不住吐槽。。。。。，继续写。。。
首先：所有语言之争都是意气之争。“xx是个烂语言”基本等价于“我就是个哗众取宠的oo”。工程师这个群体难以得到与贡献匹配的社会尊重，原因同此，nerd多有中二病。
结论：原链接po主毛病多，别理他。
下面的内容和原帖关联度并不高，因为看了一些技术经验不多的回答，一股强烈的学生气（最近看到不少貌似在校生臆想的回答被推荐呀@[email protected]），所以从商业项目的亲历角度说一点实际情况。
关于静态检查，梁前辈说的很好了，这的确不是关键。
关键在哪里？在语言的使用者，工程师。
python写小程序非常棒 -> py工程师中写小项目的比例较高 -> 用py写大型项目的案例中会出现对大型项目的不适应。
——是人。不是语言。
大型项目常见更高比例的性能挑战 -> C程序性能好 -> 用C语言的工程师大型项目丰富 -> 统计规律发现用C程序写的大型项目成功率高。
——因果倒置。统计学的常见误区。参考这个案例：统计发现增加烤箱可以降低青少年犯罪率。
另一个原因有些不好听，关于性能部分，商业（大型、高成本）软件的情况通常是这样的：
0.01%的性能不足风险，可能成为未来项目失败时被放大到99%的决策者能力原因；
所以通常关于平台、语言决策，有性能不足的风险时出于自我安全的原因，会优选高性能语言。
诚如梁前辈所言，真正有性能需要的项目不多，但是哪个项目又没有那么一丁点性能风险呢？
因为“py性能不足”原因而选择不使用py的项目，90%是用py做毫无性能问题的。例如web网站，用什么写不行啊？哪个正常语言会“写不出来”web网站么？
最后，大型项目的决策者本人的技术背景和年龄，也决定了一些项目的选型导向。
最后，举几个专业领域大家都看得出的case说明“大型项目”这个概念本身有很多方面的复杂度和挑战，举那么一两个网站的例子并不具有普遍性：
1 google把C++代码全都换成py，会挂。
2 taobao把java全部换成py，不会挂。
3 Cray把C/C++换成py，会挂。
以上案例绝对不是因为：
“py超过10w行开发效率相对于其他语言下降”
——这个观点已经被各位前辈批臭了。
匿名，因为彻底烦透了在技术讨论的时候，不看内容，而只关心“你做过什么项目，凭什么这么说”这种对人不对事的中二思维，尤其是语言之争的时候。——我没有提到什么超过一千的回答吧？
个人觉得，一切脚本语言都不适合大型项目，这是显然的。脚本嘛，就像胶水一样，主要用途是用来连接复杂组件的。这就是它的作用。
很多人都在讨论语言难易,私以为不管做什么,觉得难就是没学好.自己不行还找这个那个的理由.就像身无分文的乞丐整天奢望着能有份不用干活有有钱赚的工 作. 吾认识一只浸淫C/C艹 20+年的技术总监, 那水平就是只有想不到的,没有做不到的. 在他看来写程序是整个项目中非常简单的一个环节, 跟说话似的.
我虽然是Python初学者，但也好歹是专业人士，看完那个讨论，发表一下意见。
Python纵然很多问题，但它看起来比较“美”，就好象为毛大
家突然喜欢起Mac，讨厌Windows一样。iphone就那么好用么，快捷么，当然不是。Nokia当时搞了好多对比，发短信，搜索啊，说
iphone并不那么智能。iphone发开比Anroid快捷么，当然也不会。但就是好像"美"一点。看起来好就是好。
语法糖没什么不好，不要瞧不起，我就喜欢甜的。
但Python没有编译时检查，确实让C语言程序员崩溃，这点我不喜欢。我喜欢有微甜的，有库的，有框架的，能编译的，工程化的，轻巧简单的。
Go貌似不错，符合我的要求。
当然没有哪个语言是万能的，我的理想配置就是Go, Python+PyPy, C/C++ with lib。
python/ruby这些新（创立时间不新，但被程序员接受时，往往在他们学过几个语言之后）的语言，不仅仅支持库强大，本身的表达能力也比较强悍/精炼。
但规范性好像低了，规模大恐怕不易管理好。
但是同样的项目规模，python实现的代码会少很多；
同样的代码规模，python能实现的项目规模会大很多。
再大，才需要比较小心
我学过C/C++,java,nasm,javascript,sed,awk等等，都实际开发过，虽然经验其实很少。最后我见到python，我渐渐喜欢python的几乎每个特征，缩进，特殊的else，鸭子理论，列表解析等等！
问题的关键是标准：，
有的性能洁癖
有的追求易读易维护
有的追求优雅地处理问题，大概是python无出其右了。
《编写可读性代码的艺术》
- 可读性基本定理：代码的写法应当使别人理解它所需的时间最小化。
- 把条件、循环以及其他对控制流的改变做得越“自然”越好，使读者不用停下了重读你的代码。
- ……
豆瓣用Python和Django你敢说烂？
语言只是个工具，python作为动态语言，有快速开发的优势，遇到大项目时，架构是项目成败的关键，至于bug量，完全的团队的水平相关，与语言无关
python太方便了。。 以至于有人产生了他不能适合复杂的错觉。。。
只看到python简单的一面，没触摸到python精巧的一面。。
当然，它有缺点，还需完善。
大型项目这个问题太笼统了。
就个人看法，这个问题分成两个方面。
如果系统规模很大，内部关系很复杂，但是又不能借助数据库，一定要自己硬编码实现业务逻辑，那请远离一切动态类型的脚本语言，静态类型的语言中类型检查在这种情况下非常必要；
如果可以依赖数据库（存储过程，触发器，约束等），那用什么语言都只是个控制和表现层的东西，无所谓。
如果系统规模很大，但是核心很小，只是外部依靠插件等方式外接提供的功能，那可以选择性地使用Python在合适的地方即可。
Openstack 算大型项目了吧，它的开发语言是 Python。
python不适合做大型项目我觉得主要还是在动态语言这点上吧，也不是说不适合，而是项目一大就需要足够的掌控能力，而不像java，找个新手把框架熟悉一下就可以写的马马虎虎。
当然还一点就是GIL，不过可以通过其他方式来规避...。
直接开地图炮吧。
1 拼写经常出错你需要的是unittest和药，编译器救不了你，它只会把拼写错误变成逻辑错误，而且更难发现
2 你需要的是更好的设计，而不是更多的代码
3 50w行Python？当然吃力了，这相当于400w行c++呢。
python只是一门语言，一个工具而已，题主难道不知道openstack吗，这可是千万行级别的代码。
利益相关：个人十分喜欢用python开发，那感觉不是一般的爽。可惜被弄到做前端开发，不过前端学的一坨屎。。
工业上python做工具链挺快挺好用的
python是个垃圾的语言，是什么领域都能做都做不好的语言，在动态语言中最为复杂，缩进语意是致命的设计错误。每种语言都能开发大型程序，但不是能开 发的就适合，dos还是汇编写的呢，能说汇编比c更合适吗？豆瓣用python多用了多少机器和多费了多少人力你们知道吗？Openstack选择 python是个历史错误，可惜rackspace当年的那几个程序员不会go语言，有人用1000C++代码和pythpn几百行对比，本身就是个傻逼 的行为，几百行那是因为python把高度封装的代码做成了标准库罢了。最后的最后，缩进语义在实际开发中不会加快开发，相反它很影响开发，因为缩进本身 是属于编程风格的，但却夹杂了最重要的程序逻辑，这种设计是低智商的行为，它使得你实现功能时不仅考虑逻辑，还得考虑如何缩进来达到效果，而不是直接放在 ｛｝或者begin end中就完事了。
最近在细读第二遍Python学习手册，觉得Python的语言特性还是满精致复杂的，不过是不是符合大项目这个问题，我觉得要看具体场景，有的时候可能完全要用静态语言，有的时候可能是混合动力的，当然最后一种也不是没可能。
python实现的的开源的。。不小的项目蛮多的。。openstack之类的挺牛的～～～
感觉比较适用于开发周期短，需求变化频繁的服务中～～ 代码多了带来的复杂性，感觉所有的语言都有这个问题，不注意整体结构，码啊码自然就乱了，介个应该是设计上的问题～～
<DP>和<重构>那两本书，讲的就是这个吧,,额，，，再宏观点还有。。<soa>