2012 不宜进入的三个技术点（下）
赖勇浩（http://laiyonghao.com）C++
C++ 在2011 年其实风头甚劲，C++2011 标准出台，gcc/msvc/clang 都很快速地支持了许多新特性，新兴的移动设备的性能较差，更是C++ 的新舞台，在这个时候唱衰C++，压力很大。我使用C++ 年头不少，但除了在校的时候写过两个小游戏参加过两个比赛（分别是面向社会和面向大学生的）弄些证书好找工作以外，在工作中只用过大概不到一年半，做《斩魂》（http://zh.163.com）的早期版本，写了服务器端的几条进程和客户端的GameAI 部分。经验少，而且写得不好，所以基本上有人在weibo 上问我C++ 的问题，我都是转发给@bnu_chenshuo 和@miloyip 等真正的行家去回答的。所以实际上今天写这一篇，我底气很是不足，但是朋友们给前两篇很大面子，弄得我骑虎难下，只好硬着头皮写了。
前文提到C++ 的新标准，很有必要提一下标准化对C++ 的影响。首先我们要肯定标准定制对C++ 的积极作用，但标准化过程中的超长流程，一次次将C++ 推向深渊。C++ 的第一个标准是1998 年的ISO/IEC 14882:1998，距离整个90 年代最流行的C++ 程序库MFC（Microsoft Foundation Class Library）的第一个版本发行时间已经整整 6 年。1998 年，MFC 版本号为6.0，与其一起发布的Visual C++ 6.0 占有了巨大的市场。因为MFC 发布得标准制定的时间早，所以MFC 内部实现了许多后来标准库里也有的组件，比如各种数据结构容器。VC6 的市场占有率让windows 平台下开发的许多C++ 程序员甚至不知道有STL，同时也无视 C++98 标准，从更兼容标准的VC2002/2003 的市场占有率就可以看出来，直到今天，我知道国内不少公司还是只用VC6 的。
其实在90 年代，计算机的运算能力有限，市场上非常需要一款性能较高、抽象较强的编程语言，C++ 获得了成功，但它标准化的时间过长，造成各种编译器有各自互不兼容的“方言”，成了它的第一个软肋。第一个瞄准这个软肋的就是java，java 在1995 年推出，虽然性能稍逊，但它有更高的抽象能力、也更安全，并且更容易跨平台，所以迅速获得了成功；第二个瞄准这个软肋的是C#，微软不能推动C++ 发展，又不愿C++ 的市场被java 鲸吞，于是在2001 年推出了C#，经过10 年的发展和微软大量的金钱推广，C# 已经成功获得了它应有的江湖地位。
虽然java/c# 都不是善类，但C++ 在21 世纪的第一个十年里仍然地位稳固，这是因为Linux 和MacOS X 大获成功，在这两个平台上C++ 都是非常有竞争力的编程语言，C++ 自然水涨船高。但随着web2.0 和web app 概念的兴起，以及CPU 的主频进一步提升，服务器端编程语言渐渐地对执行效率不再敏感，而是更在意程序员的开发效率，众多的脚本语言开始蚕食C++ 的市场份额，从早期的perl 到后期的python/php/ruby，在2005 年以后，C++/java/C# 等静态类型的编译型语言的市场份额都下降了，新兴的贵族是动态语言。面对动态语言在开发效率上的强劲挑战，C++ 社区除了在2003 年对C++98 做了小小的patch，基本上睡着了，完全没有应对之策，哦不，连应用的姿态都没有。
进入21 世纪的第二个十年，市场又发生了变化，云计算越走越近，也许我们中的大部分人今天还可以说只闻其声不见其形，但The Data Center Is the Computer 这句话大家应该觉得很务实：完成一个用户操作，在服务器端的进程间通信次数前所未有地多。在这个十年，我们需要这样的编程语言：
1、能充分利用现代CPU 的计算能力，不仅仅是多个核心，更是巨大的L1/L2/L3 Cache、超线程等；
2、能够大量减小异步I/O 的性能提升的同时带来的副作用：异步编程的复杂性以及对可维护性的伤害；
两句话其实也可以压缩为一句：需要有更好的并发模型的语言。一开始大家都在已有的编程语言中寻找，然后找到了erlang，实践证明erlang 自有其局限，所以google go/scala/rust 等新语言如同雨后春笋般拨地而出。C++2011 标准努力降低C++ 的编程难度，并提供了线程库以支持现代CPU，如果在2005 年，这个标准绝对有竞争力，但在今天，它只能成为新的编程语言的垫脚石。正如IE 最大的用处是用来下载其它浏览器，不久之后，也许会流行新的冷笑话：C++ 最大的用处就是用来实现其它编程语言。
市场一直在寻找一门中间的高级语言，它上承C 语言和汇编语言，下启脚本语言。C++ 最先抢占了高地，并在与java/c# 的争斗中不落下风，但新的十年，它的对手又增加了google go/scala/rust 等新锐，并且新的标准不可能在两三年内再次出台，两三年内新锐成长起来后，留给它的位置就不多了。
上文讨论的基本上都是服务器编程，有必要再来看一下桌面和移动设备领域。首先看桌面软件，rust 是mozilla 基金会开发系统程序语言的，它的定位是部分取代C++ 开发firefox 的浏览器，所以rust 会进入桌面开发，google go 肯定会顺道啃一口。移动设备方面，主要是android、ios 和windows phone，随着移动设备性能增强，编译型语言加脚本的模式就会占大头，编译型语言方面主要是C++ 和Objective-C 在竞争，C++ 会占上风（但需求量远远小于脚本，从lua 在2011 年的增长速度可以印证），但是谁知道rust 之类的会不会进入移动设备呢，毕竟移动设备的CPU 核心也越来越多了呀，C++ 还是前景堪忧。
回首C++ 的30 年，展望它的未来，总结起来可能就是：标准化流程拖死人了。如果不是15 年不能标准化，java/c# 的搅局可能不会出现；如果在2005 年能够应对动态语言……如果云时代有更好的并发模型……
题外话：java/c# 不会有C++ 的问题，因为它们有自己的平台，有巨大的财富支撑。特别是平台的作用非常巨大，你可以想像一下如果Adobe 有自己的浏览器或手机操作系统ActionScript/MXML 会不会是今天的境地；也可以想像一下google go 的飞速发展动力是什么。
两点解释
1、我觉得有必要解释“不宜进入”一下这四个字，我想要表达的意思就是如果你现在不是这三个技术点的专家，并且手上没有使用这三个技术点的项目，进入这三个技术点仅为技术储备，那么就“不宜进入”。另外我不是说用了这三个技术点的项目就死，学了这三个技术点的人就找不到工作，或者这三个技术点明天或明年就game over，渣都没得剩，不是这样的意思，它们还会存在很长一段时间。本文不是叫专家自废武功，也不是叫已经做好技术造型的项目赶紧儿换技术，举例说，如果你选择了用java 做服务器端，flash 做客户端开发一个webgame，那你最好玩命儿地把ActionScript/MXML 和java 多线程编程（及异步I/O）给钻透，不然可能随时掉陷阱里。
2、新年新气象，工作和家庭都有很重要的事情压在肩上，大家的评论我不逐条回复了，我会在一两个星期后再统一写一篇《2012 不宜进入的三个技术点（Q&A）》统一回答，还请见谅
补充：综合编程 , 其他综合 ,
