无线网络的未来

无线网络变得越来越普遍,大如蜂窝移动通信网络,小如无线局域网。大卫•奇斯纳尔试图效仿阿瑟•克拉克,对无线网络技术的发展前景进行预测。

新千年的元旦——一个历史性的日子。世界各地的电信公司将同时取消长途资费,所有的电话都将作为本地通话计费。这听起来异想天开,但这可是大约十年前阿瑟•克拉克[1]曾经作出的预测。

事与愿违,现实总是不及愿望美好。电信运营商依旧按你拨打的被叫号码的程控交换距离来计费。然而,情况并非完全与阿瑟爵士的预言相反。这几年来我打国际长途电话付出的几乎只是宽带连接成本。但与公用电话交换网不同的是,IP电话的两端是连接在互联网上的设备。其实不管是固定电话还是IP电话,通话两端的物理链路经过的中继线缆一般都差不多。

全IP网络

英国的有线电话骨干网(由英国电信经营)和下一代无线电话网络都有一个共同点:他们本质上都是IP网络并把电话作为IP电话(VoIP)处理。我现在的手机支持UMTS [2](通用移动通讯系统),每当我使用它就会自动分配一个10/8的子网IP地址。这意味着它位于网络地址转换(NAT) 背后,因此就不能再接受入站连接。

10/8子网是最大的可分配私有网络。作为8位CIDR [3]前缀,它容许224(等于16,777,216,将近1700万)个不同的IP地址。与连接到移动电话网络的庞大设备数量相比,这根本不算多,这也是为什么移动运营商很可能率先部署IPv6的原因。采用IPv6,一家公司(甚至个人)都能轻易获得64位网络前缀,意味着前64位可用来标识网络,后64位可用来标识设备。对此可以这么理解,这家公司拥有足够的地址空间使每个有效的IPv4地址都能扩张为互联网那么大的网络,或换言之每个人都可以在他(或她)的网络上接入30亿个IP独立的设备。更重要的是,它容许全世界每台设备都具有各自唯一的IP地址,路由表记录稀少,如此路由的代价大为降低。

IPv6带来与移动电话密切相关的另一个优点就是移动IPv6,其中设备可以改变其在网络中的位置而继续保持路由,其已有的连接不会被中断。在信号塔之间移动位置通常在协议栈的底层就已经做了处理,但这种新的构架允许手机在两个彼此独立的网络之间移动同时保持连接,只要两端都采用IPv6连接。

全IP网络强调提供接入和提供服务之间的区别——一个正在被移动运营商搞模糊的分别。每当你打电话,你就在使用他们的网络,当你在使用他们的路由系统的时候,同时也在使用移动运营商与其他电话网络之间的协议。

电话号码与联系人的对应关系已经不像过去那么重要。过去我打电话的过程很麻烦:首先,我会先在一个纸质的通讯录或本地缓存中寻找对方的电话号码——要么是个电话簿或是我的大脑记忆,然后拨这个号码(后来变成了按键)。相比之下,现在我只是从通讯录中选择这个人的名字,然后就按下拨号键。最近一项研究称人们的记忆力越来越糟,因为他们连朋友的电话号码都记不住了。对我而言,不仅仅是我不再记住我朋友的电话号码——我根本就没在意那个号码是什么。很多时候,一个朋友通过电子邮件或蓝牙把电子名片发送给我,而我从来都不会去看号码那一栏。打电话(而不是联系某人)的概念看来已经依稀有些过时了。

连接的移动性

802.11标准家族不太知名的一个标准是802.11r。这个标准着眼于在无线接入点之间进行快速切换。802.11接入点在户内通常只限于几个房间那么大的范围,户外则大约一百米左右。一个走动中的人几分钟之内就可能需要在六个左右的接入点之间跳转。802.11r标准针对这个需要提供了相应的机制。如果你坐在一个与两个无线接入点距离大致相等的位置上,你或许觉察到你的网络连接不时地停顿片刻,因为你的网络堆栈在接入点之间进行切换。802.11r标准改善了停顿时间,把切换时间降低到1秒以内。这样的改进使802.11对手机用户切实可行。在安装了.11r支持的无线接入区域,你可以边走边打电话,而不会察觉你的电话在接入点之间的跳转——就像现在当你的手机在信号塔之间跳转时你根本没注意到一样。(好吧,理论上你不会注意到;实际上,你可能会察觉到)

如果所有的接入点都在一个网段上,这种切换行之有效。然而,想象你走在一条布满了接入点的街道上,这些接入点都开放并且配置在一个网络上。你从其中一头往另一头走,你打的电话被第一家的网络连接路由。当你在这条街上继续走动时,你的电话被无缝地在接入点之间切换,直到你到达另外那头。在这点上,你的电话的数据包被一打接入点中继转发给被你呼叫的那方,这不是很有效率。理想的情况下,在这点之前你就会开始用新接入点上行数据。不幸的是,每个接入点都有不同的可路由的子网地址,这样如果你切换成新的接入点来上行数据,你就会突然切换IP地址,而这将中断你的连接。

这就是移动IPv6的用武之地。IPv4也有一个针对移动的变种,依赖于三角路由——简单来说,老的网络连接充当数据包的中继,每当你移动数据包就暗中增加。对IPv6,IPSec允许安全地更新路由表。目前,切换时间大约1秒,这对VoIP电话来说还不够快,但这个切换时间有望得到改善。

对移动IPv6来说,网络间的边界变得平滑。如果你坐在一个提供免费wifi的咖啡厅,你也许就想使用咖啡厅的网络,而不是使用需要花钱的移动运营商的网络。如果你边打电话边走进咖啡厅,你当然想自动切换到咖啡厅的免费wifi网络,而不是继续使用移动运营商那资源稀缺而费用昂贵的蜂窝网络。

提供接入

移动运营商很善于根据不同数据类型来收取不同的费用。他们的整个业务模式都基于此方案。如果每条文本信息你付10美分,算下来大约折合750美元/MB。许多人愿意为短信支付这些钱,但这样的话加载InformIT首页的费用就超过500美元,而我怀疑大多数人会愿意为浏览网页花那么多钱。

你可以在你的手机上运行一个即时通讯软件,即便是XMPP这样臃肿的协议算下来其成本也只是短信费用的一部分。不幸的是,你不能用它与手机上没有装IM客户端的用户沟通,这降低了它的可用性。你不只在为IM的带宽而付费,而且也需要为网络服务付费。

电话按与别的数据不同的方式计费。这样设计更合理。然而,由于电话的要求与浏览网页和电子邮件很不一样。GSM和相关的协议用于语音通话的传输速度大约为12Kb/秒。以这个速度,你打一个小时电话也只用了大约5MB的数据流量——这在现代网络中不值一提。

然而对语音通话来说带宽并非一切。如果延迟超过200毫秒左右,你很可能就会感觉到通话质量不好。更重要的是抖动,比起延迟都还要重要。如果延迟时间稍有增加,通话的双方就会产生说与听之间的脱节。如果延迟减缓,你只有以丢包的方式才能赶上,因为你不能以高于实时的速度回放音频而没有察觉。(你可以加快点速度,但很有限)。你可以通过在每个接收端进行缓冲来补偿抖动带来的损失,但这种方法增加了延迟,而这是你极力避免的事。

所以网络接入中你在为三件事买单:带宽、延迟和抖动。对于带宽来说,你想提高就得多掏钱;对延迟和抖动,你想降低就得多花钱。即时只是提供IP连接,移动网络仍旧能通过提供不同的QoS服务质量来收取不同档次的费用。如果你想打个电话,你或许会选择具有低延迟和低抖动而费用较高的连接,你更愿意在信号质量方面而不是带宽上花钱。

软件无线电: 工程师的梦想,监管者的梦魇

随着GNU Radio之类开源项目的出现,近几年来一个有趣的发展是软件无线电。当然,无线电系统不能完全是软件的,但其需要的硬件相对简单——差不多就是一架天线和一个数模转换/模数转换器。

过去,无线电设备的执法较容易。你检查硬件是否工作在限定频率和功率范围内;如果是,你就可以核准其批量生产。

对软件无线电来说,功率和频率都由软件控制。这对监管机构来说构成问题,尤其是与开源驱动一起使用的时候,因为这意味着终端用户能轻易地把合法设备换成不合法设备。(当然,总有人可能会通过增加放大器和天线做到这一点,但是如果你只需要下载固件的补丁,事情就变得更加容易了)

尽管令监管者不爽,软件无线电的确给通信带来一些有趣的变化。当你能够把同样一台硬件用于接收HDTV和WiFi两种信号时(同时,只要你有一个足够快的处理器),就带来了很多可能性。纯软件无线电是令人难以置信的处理器密集型应用,因此对移动设备意义不大(手机专用芯片计算能力不强),但它提供了一些启示。动态配置的信号处理单元能够集成到相同的包中,这样你现在就能得到能够运行许多不同无线协议的低功耗芯片。

未来几年里设备有可能会支持WiFi, WiMAX, HSPDA, GSM和其他流行的低功耗协议,以及在它们之间进行快速切换的能力。

尽管这种变化就其自身而言并非完全有用,当与移动IPv6相结合后就变得激动人心——给你的设备一种在各种各样的协议之间跳转的能力,可以针对你的需要选择最省钱的那种协议。

什么是频谱?

可悲的是,无线电频谱是一种稀缺资源。频率越低传输距离越远,但数据传输率越低。频率高则传输距离不远。这就是为什么WiFi比移动通信快得多的原因之一。另一个是信道竞争。信号传输距离越远,你需要的接入点越少(有利的一面),而同时有更多的人在共享这个信号(不利的一面)

一些较新的发展可能会缓解频谱稀缺面临的压力,尽管它们(总是)非常占用处理器计算能力。如果你在建筑物密集的地区或丘陵地区观看模拟电视,你或许会注意到重影。这是由于一个信号从发射机直接到达,而另一个信号从山上反弹过来,延迟到达。

在建筑物密集的地区,信号会被建筑物、树木反弹,某些频率甚至能被人反弹。对于大多数现有的协议,你必须计算反弹的均值以尝试找到你真正想要的那个信号。有了更精确的设备,你有另外更好的选择。你能用不同路径的信息来确定一个特定的端点。几个设备可以在同一地区以相同频率同时发射,提供了更多可用的频谱。

虽然并非完全相关,但这种缓兵之计表明一定宽度的频谱并不意味着等量的数字带宽。技术进步允许你在同等大小的信号空间中传输更多的信号。但就目前而言,这一事实并没有改变这样的现状,即频谱相对地还是稀缺。

目前我们有两种截然相反的供互联网接入的频谱分配方式:蜂窝网络和未管制的(WiFi及其邻接频谱区间)。前者被集中统一控制,网络覆盖面广。后者不受监管,任何人都能使用,但覆盖的范围有限。

我在前面提及的一些技术使这些界线有点模糊。有线电视公司可以部署一个很高效的城域网,给所有客户提供WiFi接入,使客户能通过Mesh多路径路由和移动IPv6的组合在二者之间按需跳转。

在美国,最近作出的一项决定允许一些以前用于电视的频谱(频道与频道之间那些所谓的“空白频谱”)也可以用于数据网络。这对城域网来说是个不错的频率范围,为其实现方式提供了另一种选择。

这里可用的频率范围甚至比用于蜂窝移动通信的频率还要低,因此信号传输距离更远(毫不奇怪,只要你想想移动通信基站比电视发射塔要密集得多)。这使它对提供覆盖面广的服务很有吸引力。由于FCC(联邦通讯委员会)决定将这一范围的频谱免授权开放使用,任何人都可以开展这种覆盖业务。一个城市可以拥有许多提供快速、覆盖范围小的接入方式的热点地区,同时还有一个更大的基站以较低的接入速率覆盖整个地区作为候选。当你走在两个热点之间时,你的手机转为使用空白频谱系统,而不影响你的覆盖范围(尽管你的可用带宽可能会减少)。

未来有望看到你的手持设备能透明地在由不同服务提供商控制的和不同服务质量的网络之间自由切换。提供统一的接入服务、不同级别的最低连接质量和其他多种选择将给创新型公司带来在诸多领域建立新的商业模式的机遇。


[1] 科幻小说作家,提出卫星通信地外中继的概念,作出的很多预测也大多应验

[2] 全球使用率最高的3G移动通信标准,采用WCDMA

[3] 无类别域间路由


2010,译言网

原文:The Future of Wireless Networking - InformIT

Google搜索引擎的工作原理

搜索引擎之于Google,就像Windows之于微软,搜索引擎是互联网巨头Goolge的王牌,而今搜索对互联网来说太重要了,互联网搜索甚至已经提升到了搜索文化的高度,在海量信息的因特网上,搜索引擎是网民的罗盘,而Google做出了Internet上最好的指南针。

PPCblog.com呈现给我们一幅由Jess Bachman(在WallStats.com工作)精心描绘的示意图,这张流程图展示了每天拥有3亿次点击量的Google搜索按钮背后搜索引擎在那不到1秒的响应时间内所进行的处理。

Google(graphic) - How Google Works

这是我刚付印的最新示意图,这张流程图演示了在你点击Google搜索按钮后,在Google返回查询结果前那一眨眼的功夫里,Google是如何处理你的搜索请求的?这可是搜索巨人Google年赢利额高达200亿美元的杀手级应用,也是Internet首屈一指的商业和技术神话,大家肯定都想知道Google这棵摇钱树背后的秘密。

Google官方对其搜索技术的叙述

我们搜索技术的后端软件会在服务器侧触发一系列执行时间不到1秒的并行计算,Google问世前的传统搜索引擎的搜索结果严重依赖于关键词在页面上出现的频度,我们使用了200多个指标信号(其中包括我们拥有专利的PageRank页面等级加权算法)用来检查万维网的链接结构(佩奇和布林最初的想法是把万维网的链接结构用图论的有向无环图来建模)并决定网页的重要程度,我们假定一个网页的重要程度取决于别的页面对它的引用,就像学术论文中的引用指数一样,重要的论文总是会被很多其他论文引用。然后我们再根据搜索条件进行超文本匹配分析(对bot抓取的页面内容进行关键词倒排索引检索)确定跟搜索请求最相关的网页。综合最重要的网页和跟搜索请求最相关的网页两个方面,我们就能按重要程度和用户搜索请求相关程度把查询结果排序后呈现给我们的用户。

数据中心:Google用来索引世界的塔

Google的数据中心高度机密,我们能了解到的不多:

1. 在美国本土有19个以上的数据中心,其余17个数据中心分布在美国以外的世界各地。

2. 每个数据中心有50万平方英尺那么大,建造一个数据中心要花费约6亿美元。

3. Google数据中心是世界上最高效的设施之一,而且也非常环保,几乎没有碳排放。

4. 数据中心使用50到100兆瓦的电力,由于需要冷却,通常建在便于用水的地方。

5. Google服务器安置在一个一组容得下1160台服务器的有房子那么大的标准集装箱容器中。

处理流程

1.你写博客、或在Twitter上推微博、更新站点等诸如此类往Web上添加内容的操作

2.Google bots程序(一种作为搜索引擎构件的智能代理程序)抓取你网页的title和description、keyword等内容

(1)Google爬虫沿着链接路径周游万维网,如果没有超文本路径到你的站点,你的站点将不会被索引

(2)如果你在robots.txt中设置不许索引,Google爬虫程序将不会抓取你的网页

(3)如果链接到你站点的超文本链接上有nofollow标签,Google爬虫将不会从这些链接路径周游到你的站点。

(4)Google也能通过blog软件或xml站点地图找到你的网站

(5)从PageRank越高的网站链接到你的网站的链接越多,你的网站的PageRank就越高。

(6)Google爬虫将周游所有未标注为nofollow的链接

3.一旦被Google爬虫访问到,网页几秒内就被索引了

(1)网页内容被存储在一个倒排索引中

① 网页标题和链接数据被保存在一个索引中,用于广度优先搜索

② 网页内容保存在另一个索引中,以用于检索频率不高的长尾、个性化、深度优先搜索

(2)当你用Google搜索时,你并没有在检索时时更新的万维网,而是在检索Google的缓存,Google定期更新其索引库,在Twitter实时搜索等的竞争下,Google的索引库更新周期趋短。

4.Google基于链接评估域名和网页的总体PageRank值。

5.检查网页以防止作弊行为

(1) Google的搜索质量和反垃圾信息审查和优化算法

(2) 1万多远程测试用户评价搜索结果的质量

(3) Google征请用户对有PageRank讹诈嫌疑的垃圾信息进行举报

(4) Google接到 (美国)数字千年版权法案的通知,要求Google从搜索结果中剔除涉嫌盗版的内容

6.在对页面做了损害分析后,现在每个页面都有很多用于辅助用户搜索的数据片(比如检索关键词)反向引用着它

7.用户发出搜索请求

(1)Google搜索质量工程师Patrick Riley:在大多数Google搜索中,你的搜索处于许多并行的控制过程或Google实验室的创新项目组过程中,可以说每一个查询请求都会参与一些Google的创意实验。

8.Google会用同义词匹配与你的搜索关键词语义相近的查询结果

9.生成初步的查询结果

(1)Google当然能返回成千上万数量无限的查询结果,但一般只显示不到1000条的查询结果,出于“少则得,多则惑”的考虑。

(2)对查询结果做本地化处理,本土站点在查询结果中优先出现

10.对查询结果集按权威性和PageRank进行排序,重复的查询结果被剔除。

(1) Google根据关键词、广告类型、用户所处位置找出相关的被竞价拍卖的关键词广告

(2) 关键词广告必须遵守当地法律条文

① 广告业主的非法广告将被取缔

② 如果关键词的搜索流量过低或关键词广告点击量偏低,则会被自动禁用

③ 出于商业策略,像亚马逊这样的客户会给予优惠折扣。

(3) 关键词相关广告按收益潜力(对关键词进行竞价拍卖后的广告质量不断进行评估)排序

(4) 对广告业主来说广告内容一般都是固定的,但有时使用动态关键词使关键词广告与搜索关键词相关度更高

① 一些广告本身允许增加易变的附属信息,比如网站链接、电话号码、产品链接、地址等

(5) 当广告拥有了相当高的点击率,则会显示在搜索结果列表的上方,以使其更显眼。

(6) 其余的广告依序显示在相应的位置

11.对查询结果进行过滤处理

(1) 对通常的查询(比如在Google首页上发出的搜索请求),Google会把相关的专题性垂直搜索结果(比如新闻、购物、视频、书籍、地图等)也加到返回的查询结果中

(2) 个性化方面:用户访问过的网站在查询结果列表中会更靠上

(3) 大量使用锚点的网站有可能被从查询结果中删除

(4) 搜索结果集的聚簇性:如果网页被其他高PageRank的网站引用,则网页的重要性会大大提高。

(5) 趋势分析:对搜索流量爆增或有大量新闻的搜索关键词,Google会在新的查询结果中增加额外的PageRank权值。(Google有反映关键词搜索流量的Google趋势专题页面)

(6) 同一个域名下的多个网页如果具有相同的PageRank会被归为一组。

  1. 最终返回给浏览器端的用户一个人性化的、布局良好的、查询结果和广告泾渭分明的有机查询结果页面。

所有这些步骤在总共不到1秒的响应时间内完成,每天3亿次的点击量给Google带来了超过200亿美元的年收入。


2010,译言网

原文:Google(graphic) - How Google Works

arXiv papers

DSOS and SDSOS Optimization: More Tractable Alternatives to Sum of Squares and Semidefinite Optimization

Amir Ali Ahmadi, Anirudha Majumdar

https://arxiv.org/abs/1706.02586

In recent years, optimization theory has been greatly impacted by the advent of sum of squares (SOS) optimization. The reliance of this technique on large-scale semidefinite programs however, has limited the scale of problems to which it can be applied. In this paper, we introduce DSOS and SDSOS optimization as more tractable alternatives to sum of squares optimization that rely instead on linear and second order cone programs respectively. These are optimization problems over certain subsets of sum of squares polynomials (or equivalently subsets of positive semidefinite matrices), which can be of interest in general applications of semidefinite programming where scalability is a limitation. We show that some basic theorems from SOS optimization which rely on results from real algebraic geometry are still valid for DSOS and SDSOS optimization. Furthermore, we show with numerical experiments from diverse application areas—polynomial optimization, statistics and machine learning, derivative pricing, and control theory—that with reasonable tradeoffs in accuracy, we can handle problems at scales that are currently far beyond the reach of sum of squares approaches. Finally, we provide a review of recent techniques that bridge the gap between our DSOS/SDSOS approach and the SOS approach at the expense of additional running time. The appendix of the paper introduces an accompanying MATLAB package for DSOS and SDSOS optimization.

https://www.solidot.org/story?sid=56606

A Practical \( O(R\log\log n+n) \) time Algorithm for Computing the Longest Common Subsequence

Daxin Zhu, Lei Wang, Yingjie Wu and Xiaodong Wang

https://arxiv.org/abs/1508.05553

In this paper, we revisit the much studied LCS problem for two given sequences. Based on the algorithm of Iliopoulos and Rahman for solving the LCS problem, we have suggested 3 new improved algorithms. We first reformulate the problem in a very succinct form. The problem LCS is abstracted to an abstract data type DS on an ordered positive integer set with a special operation Update(S,x). For the two input sequences X and Y of equal length n, the first improved algorithm uses a van Emde Boas tree for DS and its time and space complexities are \( O(R\log\log n+n) \) and O(R), where R is the number of matched pairs of the two input sequences. The second algorithm uses a balanced binary search tree for DS and its time and space complexities are \( O(R\log L+n) \) and O(R), where L is the length of the longest common subsequence of X and Y. The third algorithm uses an ordered vector for DS and its time and space complexities are O(nL) and O(R).

React技术栈相关

适用

  • If you plan to build a large scale app, go with React.
  • If you want a library that is adaptable for both web and native apps, go with React.
  • If you want the biggest ecosystem, go with React.

Vue作者尤雨溪(Evan You)论React

  • 要区分两个概念:React 本身和 React 生态圈所推崇的主流应用架构
  • React 本身其实还算简单的。最简单的理解,一个组件的渲染函数就是一个基于 state 和 props 的纯函数,state 是自己的,props 是外面来的,任何东西变了就重新渲染一遍,是不是很简单?
  • Flux/Redux 的繁琐,本质上是针对大型应用的复杂度所作出的权衡:用繁琐一些的 API,换长线的可维护性。
  • MobX 是适合中小规模应用的状态解决方案,然而用 React + MobX 本质上就是一个更繁琐的 Vue

Redux – 状态管理方案

Redux 的设计思想

  • Web 应用是一个状态机,视图与状态是一一对应的。
  • 所有的状态,保存在一个对象里面。

Spring Boot

Spring Boot:构建 Spring 应用程序的现代方式

Spring Boot 基础


Spring Boot的文档
https://docs.spring.io/spring-boot/docs/current/reference/

Building an Application with Spring Boot
https://spring.io/guides/gs/spring-boot/

Building Java Projects with Maven
https://spring.io/guides/gs/maven/

Building Java Projects with Gradle
https://spring.io/guides/gs/gradle/

Working a Getting Started guide with STS
https://spring.io/guides/gs/sts/

Spring Tool Suite
https://spring.io/tools/sts/all


深入学习微框架:Spring Boot
http://www.infoq.com/cn/articles/microframeworks1-spring-boot


From Zero to Hero with Spring Boot

Brian Clozel shows how Spring Boot can help build web applications, tests to production-ready features, that leverage the Spring ecosystem.

https://www.infoq.com/presentations/spring-boot-web-dev

https://github.com/bclozel/issues-dashboard/


Getting Started with Microservices in SpringBoot
https://www.infoq.com/articles/Microservices-SpringBoot

Exploring Micro-frameworks: Spring Boot
https://www.infoq.com/articles/microframeworks1-spring-boot

Mozilla 的 Rust 编程语言

Why you should learn the Rust programming language

Discover the history, key concepts, and tools for using Rust
https://www.ibm.com/developerworks/library/os-developers-know-rust/index.html


Rust 编程语言入门

您是开发人员吗?如果是,您需要知道 Rust。
https://www.ibm.com/developerworks/cn/opensource/os-developers-know-rust/index.html


Beginner’s Guide to Rust
Get to know Rust
A compiled alternative to C and C++
https://www.ibm.com/developerworks/opensource/library/os-know-rust/index.html

Rust 初学者指南
初识 Rust
一种替代 C 和 C++ 的编译语言
https://www.ibm.com/developerworks/cn/opensource/os-know-rust/index.html


Beginner’s Guide to Rust
Start coding with the Rust language
Put your Rust skills to use by building a simple Tic Tac Toe game
https://www.ibm.com/developerworks/opensource/library/os-using-rust/index.html

开始使用 Rust 语言进行编码
运用您的 Rust 技能构建一个简单的井字棋游戏
https://www.ibm.com/developerworks/cn/opensource/os-using-rust/index.html


Why you should learn the Rust programming language
Discover the history, key concepts, and tools for using Rust
https://www.ibm.com/developerworks/library/os-developers-know-rust/index.html


Why Rust is the Most Loved Language by Developers

https://medium.com/mozilla-tech/why-rust-is-the-most-loved-language-by-developers-666add782563


Mozilla bets its Rust language will make your internet safer

JavaScript, a smash hit among programmers, made the web powerful. Now Mozilla’s Rust could protect the web from hack attacks.

https://www.cnet.com/news/mozilla-designs-rust-language-for-safe-secure-internet/


What is Rust? Safe, fast, and easy software development

The Rust language’s unique approach results in better code with fewer compromises than C, C++, Go, and the other languages you probably use

https://www.infoworld.com/article/3218074/application-development/what-is-rust-safe-fast-and-easy-software-development.html


Rust in 2018: it’s way easier to use!

https://jvns.ca/blog/2018/01/13/rust-in-2018--way-easier-to-use/

I’ve been using Rust on and off since late 2013. 4 weeks ago, I picked up Rust again, and the language is SO MUCH EASIER than it was the last time I tried it (May 2016). I think that’s really exciting!


tweets of John Carmack

Quality, reliable software can be delivered in any language, but language choice has an impact. For me, C would be a middle-of-the-road choice; better than a dynamic language like javascript or python, but not as good as a more modern strongly static typed languages. However, the existence of far more analysis tools for C is not an insignificant advantage. If you really care about robustness, you are going to architect everything more like old Fortran, with no dynamic allocations at all, and the code is going to look very simple and straightforward.

So an interesting question: What are the aspects of C++ that are real wins for that style over C? Range checked arrays would be good. What else?

Rust would be the obvious things, and I don’t have any reason to doubt it would be good, but I haven’t implemented even a medium sized application in it. I have been checking on the progress for a while, and I like what I see, but I haven’t coded in it.

值得关注的GitHub用户及项目

project

Algorithms, 4th edition textbook code and libraries
https://github.com/kevin-wayne/algs4

JavaPerformanceTuning
https://github.com/ScottOaks/JavaPerformanceTuning

Examples for O’Reilly & Associates Java Performance Tuning: The Definitive Guide

Code for the book Grokking Algorithms
https://github.com/egonSchiele/grokking_algorithms

Grokking Algorithms

An illustrated guide for programmers and other curious people

Aditya Y. Bhargava

people

Zhiqiang Zhang
https://github.com/zhangzq

Yihui Xie
https://github.com/yihui

Ruan YiFeng
https://github.com/ruanyf

Hao Chen
https://github.com/haoel

bigsai
https://github.com/javasmall

xiaolai
https://github.com/xiaolai

Brian Clozel
https://github.com/bclozel