批判Rust语言，以及C/C++为什么永远不会死
发表于 21:20|
来源http://eax.me|
作者апреля
摘要：一个C++程序员从来不会很难找到一个工资不错的工作，必要的话，可以很快的学会Rust。但相反的情况非常非常不会发生。
【编者按】此篇文章转载自Scott&Huang的GitHub，以便更多语言爱好者学习和交流，尤其是C/C++和Rust，希望对各位有用。
以下为原文翻译：
简单讲，原文是俄语，有人感兴趣，得到作者同意后，把它翻成英文。（译者：然后我再把它翻成中文。）
显而易见，这篇博文将会导致一场语言大圣战，所以，请思考两遍，确定你将会通过“有建设性的辩论”的评论参与讨论后再开始阅读这篇文章。
再次说明原文是俄语：）
注意：进一步讲，我冒昧的认为Rust有意尝试创建一个快速并且安全的语言。毕竟，Mozilla的人最初构思用它作为工具来开发一个浏览器引擎。如果它被证明是另外一个仅仅安全的语言，那么我认为
它没有达成目标。那里有许多非常不同的安全语言供人们选择和品味，如果Rust没有打算代替C++，那么：
为什么它需要包含一个不安全子集；
并且，为什么作者要抛弃Rust的轻量级进程？毕竟它们很方便，对吧？换句话说，如果我假设错了，那么整件事情就没有讨论的意义了。
如有你碰巧偶尔逛逛linux.org.ru论坛，那么请被提醒到这篇文章没有触及为什么不喜欢Rust的那10条纯技术理由。一条和亲爱的伙伴@sum3rman的Skype交谈透露出不止一种的“技术性”理由的看法。所以，我不得不承认，我下面罗列的东西不讨人喜欢，但是我还是冒险从中引用一些最感兴趣的条款到这里。实际上，一些普通共识的理由自己就足够大到不用触及技术性的讨论。
对于每一个理智程序员都非常清楚的知道的C/C++在近期不会死掉。没有人会尝试重用新语言新编写几乎所有已经存在的桌面应用程序，操作系统内核、编译器、游戏以及浏览器引擎、虚拟机、数据库、压缩工具、音视频编码解码器、一堆其他的C库等等。这是一批数量巨大的快速的、调试过的被时间证明了的代码。重写的代价太昂贵了和太冒险了，并且，诚实的讲，除了一些疯狂的Rust粉丝，没人会认为这有意义。对C/C++程序员的需求从来都是高的，并且在未来很长一段时间都是。
那么用Rust写一些新的代码怎么样？
嗯，你也许记得，这并不是第一次尝试创建一个“更好的”C/C++。拿D语言来举例。它在2001年发布，且确实是一个好的语言。但没有空间发展，没有合适的开发工具，没有著名的成功案例可以联想到它。OpenMW项目最初用D开发，但作者突然决定用C++从头重写。据他们坦白，他们收到一大堆的邮件说，“你们创建了一个很酷的项目，我想贡献一些力量给它，但是我们不懂，也不喜欢学习这个愚蠢的D语言”。维基百科告诉我们，除了D，还有有其它尝试准备杀死C++ - 举例说Vala、Cyclone、Limbo、Bitc。有多少人曾经听说过这些语言？
我觉得人们必须理解从历史中得到教训。没有一个理智的人会在他们的项目中开始使用一个新语言，直到你展示一些非常酷的开发支持工具，告诉他们一些成功故事，并且证明一堆程序员靠这个语言做日常工作维持生活。作为程序员，他们从来不会
- 除了一些最年轻的人 - 花他们的时间和健康来学习另外一种“非常棒”的语言，直到你展示一些非常酷的开发工具（不是未完工的像Racer工具那样）和许多确实准备好的库（不是“实验性的”或者“不稳定的”东西），告诉他们一些成功案例，告诉他们有许多空缺在他们的城市或乡镇。你知道，这就像“鸡和蛋”的两难处境。只有非常少的机会，这个问题确实得到解决（最近相关的案例是Go和Scala） - 这得感谢一些大公司（Google、Typesafe)的时间和金钱投入，他们基于某种理由认为值得推广一个新语言。
正如我提到的，有许多非技术性的理由单独就可以质疑Rust。但是，让我们假想一会儿这些理由都不存在。那么没有理由不用Rust写程序，对吧？好的，这一点仍然非常可疑，这么说吧。
C/C++被从很多方面批判。顺便说一下，大多数批评者还从来没有看过产品级的C++代码。简短的说，C++的问题是非常快（并且只需求一点点内存、电量，等等），但是从允许数组越界，自由的存取内存等方面看不够安全。过去，这个问题促使程序员们开发出一系列安全的语言，比如Java、C#、Python还有其他等等。但是，他们被证明和C++相比，对资源需求太多，同时还有其他一些不足 - 比如，比如当进行垃圾回收时“世界停止了”的问题。这也是为什么程序员争扎地去创建一个和C++一样快，但安全的语言。Rust是其中一个候选人。
Rust确实是安全的，但是，不幸的是，离快还差很远。在写这篇文章的时候，它和Java,go和Haskell的性能如下图所示：
我真诚的希望程序员找到一个方法来及时的加速，但直到那时，几乎没有语言比Scala或者Go对安全/速度进行妥协更加感兴趣。是否可以使一种语言同时具有速度和安全，或者是否由于对数组越界，安全包裹C语言库，或则其他一些类似东西而天生注定比C/C++慢两倍的问题仍然悬而未决。
顺便问一下，什么实际上使得Rust安全？简单的说，这门语言有内建的代码分析器，非常艰难的一条：它可以捕获全部典型的C++错误，不仅处理内存管理，而且同时考虑多线程。通过一条管道来传递一个指定对象的引用到另外一个线程，并且接着由你自己尝试使用这个引用 - 程序会拒绝通过编译。这确实非常酷。
但C++在过去30年一直屹立不倒，有大量的静态的和动态的分析器在这些时间段被发布出来。举一个例子，看一个关于Google sanitizers（明智分析器）的一个短片
- 他们确实非常难。不管怎么说，在任何一个严肃的项目中，你使用一个不断集成的系统，运行一大堆的测试来编译程序。如果你不这么做的话，那么你的麻烦比语言缺乏安全性而言会更糟糕，因为静态的类型不会保证程序按你的逻辑正确的运行！所以，由于你总是运行测试，为什么不同时使用。另一方面，如果你在你的代码的某个深处地方没有检查数组越界，并且Sanitizer也没有报告这个错误，也许，这仅仅由于所有必须的检查已经在上一层提供过了，同时，多一次检查不是会使程序变慢？即使没有sanitizers，你还可以发现许多东西供你在不同平台编译项目时提供伴随适当的失真的"assert(obj
-& isvalid)"风格论断来检查你代码的不变性。粗糙的说，这个问题实际上源自过去那些好的圣战，关于异教徒和加尔各答接近软件开发（指的是，一项创新太理想化的尝试和一个传统经验主义者认为被前者的支持者无心简单化了 - 原译者注）。
你经常可以听到一个争论说，90%的执行时间被10%的代码所执行（据我理解，仅仅是一条经验主义 - 对一个主题快速的扫描互联网无法替代任何严格的科学的研究）。因此，你可以用安全的Rust语言写你大部分的代码，然后，剩下的10%（那些“热”代码）写在不安全的子集中，所以现有的Rust实现实际上不会有不好的性能。好的，但这不更是暗示我根本不需要Rust，因为我可以用Go写90%代码，然后用C写剩下的10%？只有那些寻找银弹的人和幻想神话的异教徒会因为所有代码都100%用同一种语言编写而感到开心，而用Rust。但实际上一种语言有两者方言，这和"Java + C"或者"Go+C"组合没什么不同。
但实际上90/10规则是垃圾话。按照它的逻辑，我们可以用Java90%重写Webkit或者VirtualBox或者GCC而得到同样的结果。但这显然是错的。并不是这个比率因不同程序而变动太大，让我们做一些计算来瞧瞧。假设整个程序用不安全的C/C++编写，并且它的执行时间，假设是0.91（一小部分热代码）+0.11（大量的冷代码）=1。现在和一个用一个带有C代码插入的安全语言编写的程序做比较：
0.91 + 0.12 = 1.1，这样，理论上说，区别是10%。是多了还是少了？这取决于项目的规模。以Google为例，即使是很少的一点比例都可以节省大量的金钱（请看第五小结，“利用”，在这篇文章中）。或者想象当下一次更新，JVM突然开始要求多10%的资源！我都害怕猜想需要多少个0在数字后面才能把比率转化为金钱。10%是C和C++完成任务所需要的所有份额。
我们不停的念咒语“不成熟的优化是所有邪恶的根源”。但如果我们想逐字的跟随，为什么在所有代码里不用冒泡排序来替换快速排序？毕竟，我们没有办法确切的知道哪里是瓶颈，对吗？为什么要把普通的活动包含在actors或者事务内存中而不用马上用更加有效率的原子？并且，通常说，在小案例中，强制性的初始化每一个单独的变量，执行一堆辅助性的检查等等根本没有意义。让你仅花额外的几分钟去考虑而获取即使只有2~5%而不是10%的性能改进，其实也不坏。此外，就像我们已经指出的，这会使C/C++程序有巨大的不同！毕竟，谁敢争辩说找到了热点，重写那些代码（也许有一堆）并且证明这真的变快了是一项比预先考虑性能而言更轻松的工作？
即使除了速度/安全问题比较之外，我还怀疑那语言的设计。特别对于它使用5种指针类型。一方面，让程序员仔细考虑他们的变量存放在栈或堆里，允不允许被多线程操作的想法并不差。另一方面，想象你在写一个程序，且在某一刻发现一些变量应该存在堆里而不是栈上。所以你用Box重写代码。接着你发现你实际上需要Rc或者Arc。另外，你重写了所有的代码。接着，再次，你再次重写它在栈上拥有普通变量。所有的东西你都手工操作而没有使用一个合适的IDE。正则表达式没有帮助。或者你刚刚结束一个噩梦像“Vec&&&”
- 对Java说hello吧！但悲伤的事情是编译器已经知道每一个变量的每一件关于使用期的事，并会自动插入所有这些Box's、Arc's等等。但由于某种原因，这个责任被转移给了程序员。让程序员简单的写val（我们活在第三个千年，毕竟！）会更加方便。并且显式的在需要的地方指定特殊的Box或者Rc。从这一点看，Rust的开发人员搞砸了整件事情。这个，特别的，让Rust's的使用范围更加窄了。没有一个理智的人会用这样的一个语言写web或者服务器端软件
- 特别当考虑到它并没有提供比JVM相关语言更显著的优势。即使是Go - 带有普通轻量级的进程（不是未来) - 看起来都是一种更好的选择来解决这些任务。至于未来，你得学会如何正确的操作它们而不会砸到自己的脚
- 并且你谈到“安全”的语言，啊？确实，所有的这些语言都有他们自己的独特的怪癖 - 举“整个世界都停止了”的例子。但这个问题可以通过把代码分解成小的服务或者通过其它技术而解决。并且是的，没有人愿意把Rust转为Javascript，通过它来为AWS写脚本或则为MongoDB来做查询语言。至于安卓，它也不容易可信，但是有一个不同的理由：不仅仅只有一个架构风格，所以JVM可以做的更好。所以，如果你恰巧认为Rust是“适合所有任务”的话，我让你失望了。
还有更多的理由来终结它：
宏使用一个拐杖来弥补由于缺乏普通异常处理而导致的过度冗长。我已经写了关于元编程的问题 - 就是因为他们是特别的，导致我们没有办法得到一个合适的Rust
IDE。并且，即使我并不确定，看起来Rust宏甚至并没有命名空间。Cargo积极的鼓励绕过Crates.io从git中直接下载各种仓库就当人们是白痴。作为一种结果，我们有被被巨量的混乱的包终结的风险，就像Erlang世界中的Rabar。顺便，我怀疑Go世界有同样的麻烦。就像许多新语言，Rust在走简单化的路。我通常理解为什么它没有合适的继承和例外，但事实本身是有些人替我做决定让我觉得有些不舒服。C++不会限制程序员说哪些他们可以或者不可以做。现在，由于我们在走简单化的路，为什么不抛弃所有那些语言扩展？目前组成Haskell世界的那些东西是每个程序员用他们自己方言码出来的。智能指针，让你知道，远不会没有代价，也并不会确保一个固定时间的垃圾收集。假如一些线程荣幸的释放一个非常深的数据结构会发生什么？当死引用在一个迷宫里流浪时，所有依赖它的其他线程都安静的耐心的等待着。Erlang以及它的一小片有同样的困难 - 我曾经自己面对过它许多次。智能指针自己本身也有一些问题
- 例如内存碎片化和泄漏。就像让一个弱指针在一个循环结构里 - 整件事情搞砸了。所有这些都是一个语言试图假装变得安全点...如果你需要一个固定的GC时间，学习你程序的行为，减轻负载并且采取预防性（举例，提供对象池）如果你不满意这些数字，或者可以手工管理内存。有人看到Rust里面严格的语义描述吗？它至少有一个内存模型吗？当你考虑到它可以用10种方法翻译源代码，你还会叫它为一个“安全”的语言可以写出“确保正确”的程序？我不能，但再一次提醒你麻烦的根源通常是人，而不是技术。如果你的C++代码没有足够好，或者Java代码很痛苦的运行缓慢，这不是由于这个技术不好
- 这是因为你还没有学会如何正确的使用它。因此，你也不会因为其他一些理由对Rust满意。学习那些更流行的工具并且喜欢上它不是更容易吗？所以，总结一下，个人来说，在下一个五年左右，我会投资我的时间去学习C/C++而不是Rust。C++是一个工业标准。程序员们已经习惯用它去解决巨量的差异化的任务超过30年了。至于Rust和其他类似的 - 他们仅仅是奇怪的玩具带有模糊的优点。从2000年开始人们已经假设C++很快就会死掉，但自从那时开始起，C/C++并没有变得少用。相反的，事实上，它演进了（C++11、C++14)，新的工具发布了（举例说Clion和Clang)，并且空间巨大。
一个C++程序员从来不会很难找到一个工资不错的工作，必要的话，可以很快的学会Rust。但相反的情况非常非常不会发生。顺便说一下，找工作时，语言的选择从来都不是唯一和最重要事。另外，一个熟练的C/C++程序员可以容易的学习PostgreSQL's或者Linux核心代码，接触现代的强大的开发工具，并且有一大堆的书和文章在手（比如说OpenGL）。
所以，关心一下你的健康吧，不要浪费你的时间 - 你只有比你想象的更少的时间！ 原文地址：（责编/钱曙光）
CSDN Rust 学习交流群拥有多位Rust资深研究者，如果你想零距离接触大牛，请加群主微信 qshuguang2008 或扫描下方二维码申请入群，备注：实名+公司名+Rust。
编辑推荐本站 Rust 资源：
【专家极力推荐】（你想要的都在这里！）
【在线视频分享】【微信群分享】
【微信群分享】
【微信群分享】
【技术文章】
【技术文章】【专访】
【Rust一周集锦】、
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章序言：本文试图帮您解答“我要不要（投入大量时间和精力）学习Rust语言？”这个问题。作者尽量较少的谈及Rust语言本身，反而尝试从Rust
语言周边入手，长时间、大范围、多角度地考察，研判Rust语言是否靠谱，并给出尽可能客观的理由。为写成本文，作者Liigo不惜“卧底”Rust“老
巢”长达一年多，收集整理总结了大量信息。如果嫌长，可以只看小标题，粗略浏览一番。1. Rust编程语言Rust(blog)是一门强调安全、并发、高效的系统编程语言。其中四个关键词，系统编程、安全、并发、高效，是Rust语言的核心特征，也是区别于其他编程语言的首要因素。Memory safety without garbage collectionConcurrency without data racesAbstraction without overhead除此之外，我再补充一些关键词，以便读者更直观地了解Rust：静态类型/编译式语言/静态编译/动态编译、泛型/函数式/面向对象、模式匹配
/ADT、DST/HKT/Associated
Types/闭包(Closures)、Static/Dynamic/Multiple-Dispatch、没有虚拟机(VM)、没有垃圾收集器
(GC)、没有运行时(Runtime)、没有空指针/野指针/内存越界/缓冲区溢出/段错误、没有数据竞争(Data Race)……Rust语言具有特性丰富、设计优良、适用范围广等诸多优点。我(Liigo)从2013年底开始正式关注Rust项目，……至今有一年半了。其中有赞有批，有争有闹，也有贡献源码。本文所写的是我这些日子以来的所看、所闻、所感。判断一门新的编程语言“是否靠谱”，是主观性很大的课题。Rust语言今日才刚刚发布1.0版本，它的未来发展走向如何，谁也说不清楚，说到底都是
猜测。但是直觉告诉我，如果人靠谱、团队靠谱、技术能力靠谱、态度靠谱、社区靠谱，这个项目在很大程度上就是靠谱的、值得期待的。谨以此文，献给我长久期待的 Rust 1.0！2. 开放、友好、高效的开源社区相当彻底的开源项目，开放、透明、友好，进度热火朝天，动作大刀阔斧。这是我第一次亲身参与并观察到的如此大规模的开源编程语言项目的开发过程。（之前也关注过Go语言项目，但其规模要小得多。）开放源代码、GitHub/Git在线开发 /rust-lang/rust开放系统设计过程，重要设计项目的提出、讨论、评估、决策均在线进行(RFCs)内部决策过程也公开透明，每周发布会议记录(meetimg-minutes)公开接受第三方开发者提交的 Pull Requests，必要时还指导开发有一个核心团队(the core team)负责项目的发展方向和最终决策有大量的（超过 1000 人!）第三方开发者给Rust贡献源代码、文档和测试用例多次将优秀的第三方开发者吸纳进入官方开发团队和核心团队多次在世界各地（包括北京）主办和协办小型本地开发者见面会IRC,internals,Reddit/r/rust,HN(Hacker
News), StackOverflow有许多跟Rust相关的技术讨论，常见核心开发者参与其中Github上用Rust语言开发的项目也风风火火（详见下文）“热火朝天”，用于形容其工程量大、进度快、成效显著。看看Rust的 Release Notes，常见这类字眼：Version 1.0.0 (May 2015): ~1500 changes, numerous bugfixesVersion 1.0.0-alpha.2 (February 2015): ~1300 changes, numerous bugfixesVersion 1.0.0-alpha (January 2015): ~2400 changes, numerous bugfixesVersion 0.12.0 (October 2014): ~1900 changes, numerous bugfixesVersion 0.11.0 (July 2014): ~1700 changes, numerous bugfixesVersion 0.10 (April 2014): ~1500 changes, numerous bugfixesVersion 0.9 (January 2014): ~1800 changes, numerous bugfixesVersion 0.8 (September 2013): ~2200 changes, numerous bugfixes……还有很多就不一一列出了。Rust自从日发布0.1版，到现在的1.0正式版，平均每隔三个月发布一版，每次升级改进都多达一两
千项。Rust是在GitHub/Git上在线开发的，开发者对源代码的每一项改动（commits）都被版本管理系统记录在案，有据可查。大多数是实质
性的功能升级，不存在靠修改标点、配置文件、拼写错误、或者每改三五行代码就提交的凑数行为（在此严重鄙视Atom编辑器、Kotlin语言）。反而常见
动不动就一次提交上千行
甚至上万 行 Rust 代码的情况，例子比比皆是，。。。有一个网站叫 &This Week in Rust&，每周进展公告，专门介绍Rust语言最近一周的最新重大变动，可供大家参考。里面的内容虽然不全，但颇有代表性。这个网站几经变迁，但是自2013年6月上线时起，两年来，作者cmr坚持每周更新，几乎从未中断。总之我（Liigo）说Rust的开发“热火朝天”，一点也不夸张。（我还要顺便鄙视Apple公司，发布某某OS新版的时候，动不动就说“新增
1500项API”，哎，咱还就较真儿了，去查，算上所有Function、所有Type、Type内的所有Method、所有常量定义——
#define XX 123，你懂的 ——勉强够数！跟Rust的 &~1500 changes& 相比，天上人间。）大家可以比照近十年在中国大陆和近两年在南中国海的大型基建项目的进展速度，体会Rust那种热火朝天的开发场面。处于这样的开发环境下，所有人都深受鼓舞，所有人都知道，一切都会越来越好，知道所有的欠缺和困难都是暂时的。行动永远比语言有说服力。“大刀阔斧”，用于形容其开发行为豪迈、干脆，持续追求“更好的设计和实现”，无包袱、无迁就。只要有了更好的
设计（或实现），经过深入讨论和评估之后，果断替换掉旧的设计（或实现）。不管这项改动有多复杂、多麻烦，也不理会因此形成的大量不兼容性，勇往直前的行
动。说去胳膊就去胳膊，说卸腿就卸腿，就是眼睛它也敢摘下来镶个火眼金睛再装回去。牵一发而动全身的事情，干了可不止一次。例子有很多，最典型的是
libgreen，之前Rust靠它一条腿走路，后来有了libnative，两条腿走路，再后来全都砍掉，最终做到没有运行时(Runtime)。其他
的例子还有std::io/os/path的大型重构(I/O
OS Path Reform)，重新设计然后无缝替换回去（有rustc、servo为证），可谓自己给自己做了大型手术。一个新兴的项目，在真正面世之前的开发过程
中，如果不经历几次这类大的阵痛，很难说它最终是成熟的和久经考验的。如果因为各种顾虑而迁就、保留旧的设计（或实现），很难说最终的产品是完善的和设计
优良的。如果面世之前都不肯改进，面世定型之后改进的可能性就更小了（束手缚脚），缺陷可能伴随终生，令所有的用户长期的纠结。（这种大刀阔斧，与我
(Liigo)当年在易语言公司参与研发EF语言时我所主张并践行的观点一致。有意推迟发布1.0也是为了给完善产品留足充裕的时间。）需要强调的是，Rust开发者大刀阔斧的日子，只发生在Rust 1.0正式版发布之前。1.0之后，他们将老老实实的遵守 SemVer 2.0 规范，再也不会轻易做出破坏代码向后兼容性的行为。本文后面还会谈到这一点。3. 十年勤耕不辍、低调做人高调做事2006年，创始人Graydon Hoare启动了Rust编程语言项目，利于业余时间开发了三年，完成Rust语言的第一个可用版本。早期的Rust编译器 rustboot 是用OCaml语言开发的。这三年间发生的事情，我们现在知道的并不多。根据创始人对Rust的命名，可以一窥其设计初衷：我从很多名称中挑选出了&Rust&。主要受到病原菌的启发——那些令人惊讶的、生死轮回的、多源寄生的奇妙物种。而且&Rust&还有其他内涵：
它很好地契合了“贴近金属”(bare
metal)、“复古编程语言技术”的主题；它从字面上融合了&Trust&（信任）和&Robust&（健壮）。 —— Graydon Hoare2009年，Rust项目被Graydon Hoare赠送给（英文原文&was presented to&）Mozilla公司，并得到持续活跃地开发支持。Mozilla创建了以Graydon为首的专业团队全职开发Rust，并且开放源代码。2010年至2011年，Rust语言的编译器被用Rust语言重写，完成自举，采用LLVM作为编译后端——之前的Rust编译器是用OCaml语言编写的。2012年1月发布0.1版，第一个面向公众的预览版本问世。从那时起，平均每3个月发布一个新版本，版本号每次只加0.1，改动的内容却往往天翻
地覆。2012年到2015年这三年多的时间里，开发者持续不断的改进Rust语言、编译器和标准库，翻新重修，精益求精。不断地否定自己，不断地超越自
己，一步一个里程碑。2012年2月，也就是Rust 0.1刚刚发布不久， Servo项目被创建，用Rust语言开发下一代浏览器引擎，目的在于验证Rust语言开发大型实用项目的能力。2012年到2015年这三年多时间，Rust和Servo互相扶持着茁壮成长起来了。Mozilla公司在Rust和Servo这两个不盈利的开
源项目上付出的大量人力物力财力和时间成本，体现了他们全力打造下一代全新系统编程语言的决心和气魄。但是他们很少花费精力在大规模宣传和营销上，导致大
部分公众/开发者几乎从没听过Rust语言，仅靠长期的口碑相传吸引了一批慧眼识金的忠实的开发者。Rust不是富二代也不是官二代，它没有一个有钱或有权的爹。Mozilla公司，论资金规模和影响力，远远不及Google、Apple、Microsoft，勉强算是二流公司，但是它依然给予了Rust长期的坚定的支持。历经近十年精心打造，Rust靠自身实力赢得未来。日，Rust正式发布1.0版本，破茧成蝶，吹响进入新时代的号角。4. 定位精准而潜力广泛的应用领域现今的软件系统开发，从底层到中层到上层，大致分为以下三个层次：（底层）系统底层开发：裸金属(bare metal)、操作系统(OS)、内核(kernel)、内核模块(mod)等（中层）系统应用开发：虚拟机(VM)、容器(Container)、数据库/游戏/Web/Ftp/Dns服务器、浏览器引擎、模拟器等（上层）普通应用开发：编译器、浏览器、消息推送系统、Web应用系统、管理信息系统、其他等等其中，（底层）系统底层开发，强调对底层硬件的控制；（中层）系统应用开发，对CPU和内存的占用十分敏感；（上层）普通应用开发，更倾向于方便快捷的开发效率。通常意义上所说的“系统编程”，往往是指中底层系统开发。Liigo认为，Rust语言足以胜任这三个层次的软件开发。理由是：Rust是静态类型的编译式语言，基于LLVM生成高度优化的代码，再加上没
有垃圾收集器(GC)等额外的运行时开销，执行效率非常高，对内存的利用十分灵活，因而胜任（中层）系统应用开发；Rust具有丰富的语言特性，便捷的项
目编译和依赖管理，充分可用的跨平台的标准库，因而胜任（上层）普通应用开发；Rust支持raw pointer、unsafte block、C
ffi、asm!、No
runtime，因而胜任（底层）系统底层开发。Rust语言特别强调并保证的内存安全，对于三个层次尤其是中底层，是额外的突出的加分项。上面的论述偏向于理论，可能不如实践有说服力。下面我们看看现实中Rust已经做到了什么程度（不是能做什么，而是做了什么，咱们靠事实说话）：底层开发： rustbootrustosbarebonesreenix5stepsothers中层开发： Servo浏览器引擎 Piston游戏引擎 HyperHTTP服务器SprocketNESNES模拟器LlamaDB数据库上层开发： Rustc编译器 Cargo项目管理Iron&NickelWeb开发框架ConrodGUI库早在2013年我(Liigo)开始关注Rust之前，那时候Rust还有可选的GC，还有不算小的Runtime，还有笨重的标准库。即使在那种
情况下，都有人不断地尝试用Rust做底层开发（参见前面的链接）。后来，Rust有了几个大的动作，令其更加胜任系统底层开发工作：拆分标准库(std)，提取出专门针对底层开发的极其轻量级的核心库(core) RFC #40 Issue #13851: Make std a facade PR #13901: Refactor libcore out of libstd old移除运行时库 RFC #230 PR #18967: Finish runtime removal PR #17673: remove librustuv PR #18557: remove rtio PR #19654: remove librustrt删掉GC RFC #256 PR #17666放弃分段式栈 Abandoning segmented stacks in Rust支持静态编译 PR #10528: Add static linking to rust添加#![no_std]属性 no_std 允许用户放弃使用(功能丰富但相对笨重的)标准库(std)，选用更底层更轻量级的core,libc,alloc,collections等
库，Option/Result/Iterator/Deref/Cell/String/Vec/HashMap等基础类型依然可用。更绝的是，你甚至
可以连core也不用，纯裸奔(参见本人旧作)。由此可见Rust为支持底层开发不遗余力。能做到这一地步的系统语言还真不多见。Rust是名副其实的系统编程语言，在这个领域，它不惧怕跟任何对手竞争。向下，Rust可取代C语言地位；居中，Rust可挑战C++市场，向
上，Rust可向Java、Python分一杯羹。总之，Rust精准定位于中底层系统应用开发，上可攻下可守，适用范围相当广泛，具有全能型选手的潜
质。开发者们学习Rust语言，不怕没有用武之地。5. 自举（用Rust语言开发Rust编译器）Rust在2010年至2011年完成自举，使用Rust语言开发出Rust编译器rustc， 取代了之前用OCaml语言开发的Rust编译器rustboot。Rust标准库，很早就是Rust语言写的。这意味着，早在四年前，Rust
早期核心开发人员，就已经是全职的Rust程序员了，一天八小时，几乎完全使用Rust语言编程：用Rust开发标准库(和其他库)，用Rust调用标准
库开发编译器，用编译器编译标准库和编译器。等到1.0发布时，他们已经是具有多年极其丰富的Rust开发经验的程序员，这期间他们积累的大量设计开发经
验和教训，无疑不断地推进了Rust自身的迭代更新。有人说：没有必要自举，不自举不代表它没有这个能力。这话说的没有太大毛病。但是我们考虑如下两点：1、自举从事实上印证了它（编程语言+编译器）具备这个（强大的）能力，不自举只能在理论上保留它具有这个能力的可能性，两者不在一个层面上，说服力孰强孰弱不言而喻。新语言在大规模推广之前，往往欠缺这种说服力，进而导致推广不利，陷入怪圈不能自拔。2、自举过程中和自举之后，核心开发者每天使用自己开发的语言工作（开发自己的编译器），不断的在实践中锻造，利于及早发现设计缺陷和不足之处，并
及时解决；自举之前，只能每天花费大量的时间和精力，使用其他编程语言开发和维护自己的编译器，学习积累的都是别的语言的经验和教训，缺少在实践中检验自
己设计的语言的机会。如果自己设计的语言自己都不去深度地使用，又上哪里获取第一手的反馈信息呢，又如何改善呢。所以自举越早对编程语言自身发展完善越有利，最好是在自身定型之前尽早自举。在编程语言自身定型之前尽早自举，这句话说起来容易，实施起来却非常困难。语言不完善，某些功能就可能暂时没法实现；语言不稳定，需要不断的修正和
改进，用它写的编译器也需要相应的大量的维护更新甚至重写，是很大的工作负担。所以很多新的编程语言的作者，不愿意（尽早）自举，相应地也就永久失去了自
举带来的好处。我（Liigo）举两个反例：第一个是Google公司的 Go语言，截
止到2015年，其编译器和运行时库，包括语言核心数据结构和算法map、channel、scheduler等等，还是用C语言开发的（正陆续替换为
Go）——他们的核心开发人员真正用自己开发的Go语言进行实际的大型应用开发的机会并不多。虽然标准库是用Go语言自己写的，但他们却没有大范围使用标
准库的经历。实际上，他们缺少使用Go语言的实战开发经验，往往不知道处于开发第一线的用户真正需要什么，无法做到设身处地为程序员着想。缺少使用Go语
言的亲身经历，也意味着他们不能在日常开发中，及时发现和改进Go语言设计上的缺陷和不足。第二个反例是中文编程的翘楚 —— 易语言，它的编译器、核心支持库、集成开发环境(IDE)，和绝大多数支持库，都是用C语言或C++语言开发的，他们的主要开发人员，包括创始人
吴涛在内，每天的工作是熟练编写大量C/C++代码，写易语言代码的机会少之又少，即使有也是写一些调用支持库的示例这类浅尝辄止的代码。事实上在易语言
研发部，只有庄晓立(Liigo)、袁晓辉(海洋)、龚辟愚(GBB)等少数几位具有较深的易语言功底，其他开发人员进入研发部之前甚至都没听过易语言。
吴涛本人早年还写过一些较大的易语言程序，代表作是俄罗斯方块（代码多达500行），后期也很少写了，偶尔写一些Sample代码作为支持库的示例（往往
不超过100行）。易语言公司里写易语言代码最多的应该是项目教育培训等部的史世恒、潘春华、季翔、王军、张志恒他们。后来易语言暴露出来一些大的设计缺
陷，已经不好修复了，除非伤筋动骨地翻修（放弃向后兼容性）。再后来吴涛组织团队又开发了全新的编程语言“易语言.飞扬”（EF），发布之前用EF语言开
发了自己的集成开发环境(IDE)，是一大进步，但依然没有完成自举。后来听说吴涛自己在搞3D游戏引擎(Volcano3D)，好强大，希望推出真实的游戏（而非demo）检验其优秀品质。而Rust语言，偏偏克服了诸多困难，提前4年完成自举，成为是最成功的案例之一，充分的享受了自举的好处，不断地在实践中完善了自身的设计。没有深度的实践，就没有优秀的设计。除了自举，Rust还有其他的深度实践。6. 两个半&大型成功案例&: servo, rustc+std, cargoServo: 下一代浏览器渲染引擎（类Webkit/Blink），超过40万行Rust代码Servo是Mozilla公司另外一个独立开发组的项目，启动于2012年初，跟Rust并行开发。多年来，在Rust语言从幼年到少年逐步成
长、长期剧烈变动的情况下，Servo居然还能保持正常开发进度，实属不易。Patrick
Walton在Servo开发组和Rust开发组都是核心程序员，Servo组的Lars Bergstrom经常参加Rust组的每周会议，这保证了两部门的有效沟通。Rust组经常会优先协助解决Servo组遇到的问题，维持Servo开发任务正常推进。对于Rust而言，Servo项目存在的最大意义就是，它实践并印证了Rust语言具有实际的大中型项目开发能力（而不仅仅停留在理论上），同时获
得了珍贵的设计开发经验和教训，反过来进一步促进了Rust自身的发展。Rust语言和标准库逐步发展到今天，许多优秀的设计得以引进，许多有缺陷的设计
得以改良，都要感谢Servo这类大型实践项目，在Rust
1.0之前就已经长期存在。试想，如果Rust定型之后才启动Servo项目，实践中发现语言的重大设计缺陷又能怎样，反正木已成舟，悔之晚矣。Servo已经通过了 Acid2 标准测试；可以 并发渲染 Github/Reddit/CNN 这类大型静态网页，性能 明显高于 当前的Firefox浏览器的Gecko引擎；可以无缝替换基于Chrome的 CEF 框架；已经实验性的应用在Firefox OS平台(b2s)。2015年将发布测试版浏览器。Servo有机会成为浏览器历史上里程碑式的产品。rustc+std: Rust编译器和标准库，超过35万行Rust代码时至今日，rustc负责编译全世界所有的Rust源代码，包括rustc+std的35万行和servo的40万行，以及crates.io网站上的2000多个第三方库，是名副其实的大型成功项目。Cargo: Rust的package管理器，项目依赖管理代码量相比前两者而言要小的多，所以我算它是半个成功案例。代码虽少，但实用性、流行度有过之而无不及。全世界大约99%的Rust项目采用
Cargo编译。crates.io网站上有2000多个包，总下载量超150万次。Cargo最大幅度地简化了Rust项目的编译和依赖管理，可以说是
目前开发Rust项目的必备工具。7. 十分重视并认真对待1.0版本Rust
1.0被开发者视为第一个稳定可靠的可用于生产环境的版本。也就是要承诺：现有的大部分语言特性和标准库API要稳定下来，以后不能轻易改变，非得要变得
话也得保持向后兼容；功能上要基本全面，至少要满足基本的软件开发需求，不能有明显的欠缺；质量上要有可靠性保证，不能动不动就这里有问题那里有问题。此
外，还要给语言将来的发展留足余地。官方博客Road
to Rust 1.0 对于 1.0 有详细的阐述。任何认真的新编程语言面临“何时发布1.0版”这个问题时都会感到纠结。发布的越早吧，初级产品没经过多少实际检验，用户量一上来用的人多了，很可
能爆出基础设计缺陷，不得已大幅翻修，导致口碑不佳，然后无人问津，项目就算失败了；发布的越晚吧，影响力小用户量一直上不去，也得不到太多实际检验，始
终达不到1.0的水平，可能就一直默默无闻下去了。Rust在1.0发布时机上把握的还算比较到位：诞生快十年，高速发展三五年，吸引了一大批用户，自身
也经过的“两个半”大型项目的实际检验。要说早，肯定是不早了。Rust没有盲目的早早发布1.0（例如在2012年），是因为他们对1.0期待很高，他
们对自己要求很高，他们心里有一杆秤。因为他们是认真的。为了在2015年5月保质保量发布Rust 1.0，他们提前做了哪些工作？7.1. 标准库API的稳定性Rust为标准库内所有API，即所有fn、所有type(struct/enum/trait)、所有method、所有impl、所有
const/static、所有macro_rules!，都逐一标注了稳定性标签：stable、unstable或deprecated。并且声
明，1.0版本内包含的所有stable API，都将在SemVer
2.0规范下得到向后兼容性保证，今后所有1.x版本都不会破坏其稳定性（除非遇到重大BUG不得已而为之）。我们去查Rust开发组公开的会议记录，会发现在日到10月1日，共有8次API review专题会议()，逐一审查确定各API的稳定性标签。此后更长的时间里，又不定期的将更多API标注为stable或unstable/deprecated，在rust repo里搜索&stabilize& 可以得到大批提交记录，显示出这项系统工程显然不是一朝一夕所能完成的。目前标准库名下stable API大约有2500条，占总数的80%。新生编程语言中能做到这个程度的，很少见。7.2. 精益求精的API设计Reform: Collections reform(v1: RFC #235v2:
RFC #509) RFC #369: num reform RFC #439: cmp ops reform RFC #453: macro reform RFC #474: path RFC #517: (big) io os reform (including net fs process env osstr etc.) RFC #1040: Duration reformRevise: RFC #48: revised trait matching RFC #132: revised UFCS Issue #18469: revise coercion rules PR #22435: revise std::thread PR #11263: revise btreeStabilize: PR #17029: Vec PR #17438: String PR #23549: num PR #22975: ffi and othersEntry API: RFC #921: entry v3 (v1v2)PR
#22930String Parterns: RFC #528 PR #22466 PR #23952Audit: Issue #22820 PR #24447 PR #22715 othersAPI review: meeting-7.3. 精益求精的类型系统设计改进接口匹配算法: /rust-lang/rust/pull/17197新的类型推导机制: /rust-lang/rust/pull/15955逐步完善DST系统: /rust-lang/rust/issues/12938继续 优化 (RFC #1023)orphan rules，确保向前兼容（向未来兼容）…7.4. 精益求精的文档和代码复审&Guide: Hello Cargo&经过仔细review: PR #15183&Guide: Strings&经过仔细review: PR #15593&Guide: Pointers&经过仔细review: PR #15789&Guide: macros and unsafe&经过仔细review: PR #16331&A 30-minute Introduction to Rust&经过仔细review: PR #16641&Rust book: guessing game&经过仔细review: PR #25080&Rust book: stack and heap&经过仔细review: PR #25292&Rust book: dining philosophers&经过仔细review: PR #25321&Rust book: concurrency&经过仔细review: PR #21152&cross-compiling for iOS&经过仔细review: PR #14751&regex crate&经过仔细review: PR #13700&flexible target specification&经过仔细review: PR #16156&RingBuf&经过仔细review: PR #18747 PR #19569&HashMap&经过仔细review: PR #16628 PR #19946&Rustdoc: sidebar tooltips&经过仔细review: PR #20021&Rewrite associated types&经过仔细review: PR #20307&new std::path&经过仔细review: PR #21759&String patterns&经过仔细review: PR #22466&primitives inherent methods&经过仔细review: PR #23104&floating-to-decimal formatting&经过仔细review: PR #24612&Vec::drain&经过仔细review: PR #24781&Redesign Duration&经过仔细review: PR #249207.5. 1.0之后的开发计划1.0是起点而不是终点，1.0之后Rust还将持续不断地开发新的语言特性，打造更完善的标准库。核心开发者Niko Matsakis在今年4月份发表 Priorities after 1.0 一文，详细阐述了1.0之后的开发任务、计划、优先级，内容很多却安排有序，体现了他们对这些问题的深度思考。此文在开发者社区中引起强烈反响，获得热烈讨论。Niko还发表了系列博客文章的第一篇&Virtual Structs
Part 1: Where Rust’s Enum Shines&。8. 精心设计的规范透明的开发流程在2014年3月之前，Rust开发组并没有十分规范的开发流程，基本过程是这样：修改代码，提交PR，Review，Merger。这样导致的问
题是，没有形成设计文档，一旦遇到较大规模的代码改动，别人想理解他的设计思路，首先要读懂他的代码，这给方案评估、代码评审制造了困难，而且容易形成无
人理解或难于维护的代码。从2014年3月开始，Rust引入了规范化的RFC流程。规定，对语言重大改动之前，需先提交RFC文档，写明包括意图、详细设计、优缺点等在内
的完整技术方案，供社区集体讨论，最后提交到Rust核心开发组每周的专题会议上评估审核，获得批准之后才进入实施阶段（代码实现）。规范化RFC的好处
是，首先形成了完整的技术文档，利于集体讨论、评估（进而优化方案），利于方案实施、后期维护，而且利于核心开发组主导项目进展方向。RFC流程实施一年
来，在Rust发展过程中发挥了极其深远的作用，先后通过了一大批十分重要的RFC，有力地推动了Rust语言的革新。6个继承RFC: PR #5PR #9PR #11PR
#142PR #223… 这些都是提案，暂时没有胜出者，所以都没有RFC编号。1.0之后将决出谁是最佳可行方案。associated items: RFC #195io os reform: RFC #517collections reform: v1: RFC #235 v2: RFC #509Scaling Rust’s Governance: RFC #1068举一个例子，说明社区会主动监督开发流程的规范性和透明度：2014年8月，官方人员aturon居然想偷偷摸摸地把unwrap方法改名为assert， PR #16436: API conventions cleanup(80+)，被网友 发现(120+) 后引起极大争议。争议的起因是他们工作透明度不够，事先 公示(50+) 范围不足，未得到充分讨论。最终这一改动被迫撤消。9. 不拘一格聘请专业技术人员Steve Klabnik之前写过一篇介绍Rust的入门教程 Rust for Rubyists，文风娓娓道来，深得群众喜爱。2014年2月，Rust官方人员看重了他的文档写作才华，付费 聘请 他全职为Rust 创作文档。他的主要代表作是Rust官方的 The Rust Programming Language(Rust Book)，以及大量API Docs。因为其卓越贡献，steveklabnik目前已经是Rust核心开发组 成员。Tilde公司以前开发的Ruby包管理器Bundler在Ruby领域非常流行，其架构设计被实践证实获得成功。2014年3月，Rust官方 宣布 聘请 Tilde公司的核心技术人员Yehuda Katz和Carl Lerche，全职为Rust设计开发全新的开源的 Cargo，目标是打造世界级的包管理器(&a world-class package manager for Rust&)。现在Cargo已经初步获得了很大的成功，还在蓬勃发展中。因为Yehuda Katz的突出贡献，他已经成为Rust核心开发组 成员。深受好评的Rust学习示例网站
的早期创建者 Jorge Aparicio(japaric) 后来被邀请 加入 了（Mozilla公司的）Rust官方团队。去 meeting-minutes 里面搜索 &Friend of the Tree& 或 &fott& 你会发现更多人陆续加入了Rust团队。10. 大规模的广泛的社区参与社区用Rust开发的或与Rust相关的开源项目进展地风风火火: Servo, Cargo,rust-by-example,Hyper,Piston,coreutils,rust-postgres,gfx-rs,conrod,rust-sdl2,rust-crypto,docopt.rs,zinc,gl-rs,racer,rust-bindgen,glfw-rs,capnproto-rust,rust-rosetta,graphics,rust-openssl,rust-encoding, hematite, capnproto-rust, glium,html5ever,glutin,rust-layers,rust-serde
……我上面列出的多是长期以来持续开发和维护的项目，这在Rust语言长期剧烈变动的情况下愈显弥足珍贵。理智的人们不会无缘无故的花费大量时间和精力。许多忠实的第三方开发者长期地投资Rust项目，体现了他们对于Rust语言的热爱和对其前景的看好。10.1. 社区合力完成的项目(libextra, diagnostics)：10.1.1. 分解extra库 Issue #8784：/mozilla/rust/pull/11787 (flate)/mozilla/rust/pull/11867 (arena glob)/mozilla/rust/pull/11912 (uuid)/mozilla/rust/pull/11939 (sync)/mozilla/rust/pull/11945 (term)/mozilla/rust/pull/11984 (serialize)/mozilla/rust/pull/12007 (getopts)/mozilla/rust/pull/12010 (collections)/mozilla/rust/pull/12012 (semver)/mozilla/rust/pull/12154 (num)/rust-lang/rust/pull/12200 (base64 hex)/rust-lang/rust/pull/12343 (test)…10.1.2. 详解编译错误Issue #24407：/rust-lang/rust/pull/24431 (E0297, E0301, E0302, E0162, E0165)/rust-lang/rust/pull/24455 (E0152, E0158, E0161, E0170, E0306, E0307)/rust-lang/rust/pull/24482 (E0009)/rust-lang/rust/pull/24488 (E0015, E0020)/rust-lang/rust/pull/24525 (E0018)/rust-lang/rust/pull/24552 (E0133)/rust-lang/rust/pull/24728 (E0271)/rust-lang/rust/pull/24966 (E0282)/rust-lang/rust/pull/24975 (E0079, E0080, E0081, E0082, E0083, E0084)/rust-lang/rust/pull/25190 (E0046, E0054)/rust-lang/rust/pull/25200 (E0062, E0063, E0137)/rust-lang/rust/pull/25272 (E0184, E0204, E0205, E0206, E0243, E0244, E0249, E0250)/rust-lang/rust/pull/25398 (E0053, E0066, E0069, E0251, E0252, E0255, E0256, E0368)/rust-lang/rust/pull/25422 (E0197, E0198, E0199, E0200)…10.1.3. 排错语言手册Issue #1667610.2. 社区广泛参与的大型技术讨论：10.2.1. inherents:围绕实现“继承”这一语言特性，社区涌现出一批设计方案，一时间争奇斗艳。暂时没有结果，最终决策要在1.0之后才能做出。（括号内是评论数，下同。）RFC PR #5: Virtual structs(10+)RFC PR #9: Fat objects(20+)RFC PR #11: Extending enums(10+)RFC PR #142: Efficient single inheritance(60+)RFC PR #223: Trait based inheritance(40+)Summary(40+)inheritance meeting
10.2.2. scoped thread:日爆出这个大BUG(Issue #24292)，直接拷问Rust“内存安全”核心概念，当时距离1.0发布已不足5周时间。要知道，刚刚一天前，std::thread::scoped()还被官博
当作既安全又典雅的优秀API的典型、满怀骄傲地向全世界推介。是不幸，还是该庆幸？我认为该庆幸，有机会消除一个隐患，而不是在不知情中带着重大缺陷进入1.0。Issue #24292: std::thread::JoinGuard (and scoped) are unsound because of reference cycles(30+)RFC #1066: Alter mem::forget to be safe(270+)RFC PR #1084: Scoped threads, take 2(90+)RFC PR #1085: Leak and Destructor Guarantees(70+)RFC PR #1094: Guaranteed non-static destructors(70+)Pre-Pooping Your Pants With Rust(100+)On reference-counting and leaks(110+) anda
few more官方人员一味的强调 Issue #24292
是个例，一味的强调“不保证析构函数务必执行”不违反内存安全，并不能消除群众心中的不安全感。在我看来，官方人员给出的解决方案（RFC PR
#）一个是“头痛医头”一个是“脚痛医脚”，反而是民间技术人员提交的方案（RFC PR #1085
#1094）更接地气，至少是朝群众期望的方向努力了。可能是1.0发布日期逼近，实在没有时间评估和实施其他方案，最终官方坚持通过了RFC
#1066。这一次我给他们集体评负分。好在他们广泛深入地参与了所有相关的讨论，内部无争议地做出了理性决策，结果未必坏。10.2.3. mutable & unique:Rust社区对于可变性(mutable)和唯一性(unique)的反思和争议。所有这些话题，都引发了许多热烈的讨论和激烈的争论，火热程度空前。之前 /r/rust 内评论数达到200+的极为少见。先是RFC 58，DaGenix 要求把 &mut 改为 &only(50+)再是 Nicholas 要求彻底取消mut，增加 unique(240+) 引用还有pcwalton发出的 追问(180+)：谁表达更清晰，可变性(mutability)还是唯一性(uniqueness)？10.2.4. othersint/uint => isize/usize:integer overflow:reddit/HN hot posts:Rust中文社区(rust.cc, 新手QQ群:)大量的、广泛的、深入的社区技术讨论，体现了人民群众积极参与Rust开源项目的热情。多个体、多角度、多出发点的争论，有利于参与者充分认清同一个技术问题，有利于鉴别各方案的优缺点，有利于折中优选最佳可行方案。优质社区是Rust发展的基石。当多方争论不相上下的时候，我们发现，Rust拥有一个坚强的核心团队(the core team)，总是会应急出面，充当主心骨，做出最终的理性决策，避免出现互相扯皮却始终一事无成的最坏结局。他们的实力是有目共睹的，他们的信誉是逐步赢得的，他们做出的选择，不一定是最优的，但一定也不差。～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～全文完，感谢！（翻页到这里也不容易呀，顺便吐个槽吧:）~　
　文章为作者独立观点，不代表微头条立场
的最新文章
说起黑客，如果你觉得他们只会黑一黑电脑、手机，那可真是瞧不起人家的职业水平啊。最近几年，黑客的魔爪已经伸向医32位微控制器世界向Linux敞开大门。前一段时间，领先的ARMCortex-M供应商意法半导体（ST）发布 InfoWorld在部署、运营和保障网络安全领域精选出了年度开源工具获奖者。最佳开源网络和安全软件BIND在不久前结束的2016 MWC上，Ubuntu不仅是展示了全新的平板电脑，手机，云服务开发环境，还确认了与企近两年来，Linux的容器技术占据了世界企业IT市场的主导地位，并且基于很好的理由-除此之外，它们所承担解决　　Canonical今天宣布联合SAMSUNGARTIK物联网生态系统加快物联网应用和服务的开发。CanoAndroid Studio的优点之一就是更新迭代速度很快。每次新版发布都会带来一系列的新功能、新工具，并修Apache Spark在2015年得到迅猛发展，开发节奏比以前任何时候都快，在过去一年的时间里，发布了4个　　TIOBE采用搜索引擎评级追踪编程语言的受欢迎程度。在今年1月，Swift编程语言超过了Objectiv把二次元人物带进这个纷繁脏乱的三次元世界，是众多宅男一直以来的梦想。在日本，有开发商就把全息投影技术放进Swift是苹果设计用来取代Objective-C的，自2014年6月发布以来，其应用迅速发展。苹果的Swi如果说2015年无人机消费者市场刚刚起步，那么2016年则是人们将好奇心与创造力与无人机相结合，冲击人类想象力极限的一年。　　"计算机科学里两件最难的事：缓存失效和命名。"Codelf通过搜索在线开源平台Github, Bitbu亚马逊上什么都有卖，但你知道吗，他们私底下其实也有在发展自己的芯片业务呢。只不过，这些被冠上「Alpine」　　Oracle在2015年的DB-Engines排行榜上，相比于其他290个监控的系统都更受欢迎。所以，D2015年是新开源项目风生水起的一年！大到从企业解决方案、小到家庭应用都酝酿着各式各样的开源产品！很多开源项　　日，当时还只是芬兰赫尔辛基大学计算机科学专业的Linus
Torvalds给一群程序新年伊始，Docker公司宣布，著名的Debian创始人IanMurdock已经去世，享年42岁。他同时也是　　Larry Wall发布消息：Perl6于日22:00GMT时间发布了！按照承诺，发当面对容器技术时，安全性往往是人们最为关注的问题。开发人员喜爱容器，某些运维人员也对其赞赏有加。但如果使用不近日，家住费城的Dylan Pierce做了一面“魔镜”。整体效果，以及跑程序时的状态如图1所示。他用RasLinux基金会刚刚宣布，和20多家企业共同合作研究，统一并开发数据区块链技术（blockchain tec　　当前物联网（IoT）大潮奔涌不止，畅游其中的乐趣岂是隔岸观风景之人所能体会的？绝大部分物联网框架变得有血　　Linux社区好几个重要的日子，每年都得纪念一番，比如说Linux内核的生日——日，比　　Larry Wall发布消息：Perl6于日22:00GMT时间发布了！按照承诺，发　　路透社12月27日报道称，根据两名深入研究过朝鲜自主开发操作系统代码的德国研究人员表示，朝鲜自主开发的计　　售价1万多的机器人也能像小米手机一样瞬间售罄？没错，这就是Pepper。昨日，软银在日本开始了这款“情感　　目前摆在Ubuntu系统面前的诸多问题之一就是只有Nexus
4设备支持通过MHL连接来输出视频。其他　　“程序猿”常常戏称，GitHub是全球最大的同性交友网站。　　只不过，在GitHub上交友十分特别，你可2015年只剩下一周了，回过头看看发现2015异彩纷呈，称为开源之年也不过分。企业用户以前所未有的速度拥抱开　　据techrepublic报道，每年的年底，总是有很多评论者和预测者喜欢猜想来年的情况，为了秉承这种传统　　Ubuntu项目的最高领导人之一达斯汀柯克兰日前在一封给Ubuntu社区的公开信当中透露，全球Ubunt图片来自New York Public Library二百年前的今天（英文原文发布于12月10日，译注），正 深度操作系统是一个致力于为全球用户提供美观易用、安全可靠的Linux发行版。经过将近一年的磨练，深度操作系还记得那年的毕业典礼，老爸送了我一台电脑，它拥有512MB的内存和一颗奔腾的芯。与之一起到来的还有Windo扎克伯格将女儿麦克斯扮成“星战勇士”。　　国际在线专稿：据秘鲁《商业报》12月17日报道，17日，Faceb2011年，Ubuntu发行版的创始人Mark Shuttleworth在Ubuntu开发者峰会定下了一2015是开源盛世的发端，而不是顶点，2015年开源运动所呈现的发展趋势牵动着整个IT业的神经。近日开源深度商店为您提供数以千计的精品应用，只需要轻轻一点，即可快速获取！深度商店 V4.0拥有全新面貌，UI界面设lupaworld中国最全面的开源社区,宣传开源精神,推进开源运动,搭建服务平台,共享开源技术。我们致力于通过软件技术改善中国软件行业现状。推进LUPA人才芯片工程来解决部分大学生就业问题.热门文章最新文章<img title="永久脱毛极致光滑" alt="永久脱毛极致光滑" src="http://img01./net/a/04/link?appid=&w=394&h=150&url=/mmbiz/h6HNASbmgxbrPw1lBkxlDXOyrj9Yewu8k0WUYGPZFcUC3gqc4W6J3qrIfLdTUR2QUibib2LztHSRnibwnhbsNpFew/0?wx_fmt=jpeg" rel="nofollow" width="394" height="150">2.永久脱毛极致光滑lupaworld中国最全面的开源社区,宣传开源精神,推进开源运动,搭建服务平台,共享开源技术。我们致力于通过软件技术改善中国软件行业现状。推进LUPA人才芯片工程来解决部分大学生就业问题.}