Q新闻丨Linux基金会迎来JavaScript社区；开源搜索引擎Elasticsearch 5.0版发布；Rust 2017…

本周要闻：上周，Linux基金会迎来了新的JavaScript基金会的加入；开源搜索引擎Elasticsearch5.0版本正式发布；2017，Rust将何去何从？...



“

本周要闻：

上周，Linux基金会迎来了新的JavaScript基金会的加入；开源搜索引擎Elasticsearch 5.0版本正式发布；2017，Rust将何去何从？

上周，Linux基金会迎来了新的JavaScript基金会（JS Foundation）的加入。

该新闻是由新的JavaScript基金会的执行董事Kris Borchers宣布的。他同时说明，JS基金会的目的在于“支持各种各样的技术，对整个JavaScript生态系统中的项目给予补充”，其中包括了客户和服务器端的应用库、移动应用测试架构和JavaScript引擎等。

所有jQuery基金会的项目也将会合并到新的JS基金会中，包括了jQuery、Lodash、Esprima、Grunt、RequireJS、jQuery UI、Globalize、Sizzle、Jed和Dojo。

IBM云技术和架构副总裁Angel Diaz说，新的JS基金会对JavaScript社区来说是一个是令人兴奋的事件。

通过将JS基金会与关注核心平台技术和应用层的社区团结在一起，业界正在建立一个借助代码、协作和社区开发开放地驱动创新的工作重心。

我们很自豪能成为JS基金会的创立成员，并据此延续我们支持开放技术社区的悠久传统。我们相信该JS基金会将为开放式管理的JavaScript项目设置规则。

JS基金会采用的开放技术管理模型中，包括了技术咨询委员会（Technical Advisory Committee，TAC）和理事会。TAC为项目提供技术建议，并将JavaScript生态系统中可见的技术机会通知理事会，理事会负责业务决策和市场营销。

JS基金会推出了整套的全新开放技术管理架构，一并推出的还有被基金会宣称将鼓励社区中的“合作和可持续发展文化”的“导师计划”（Mentorship Program）。

导师计划中所迎来的第一批项目包括Appium、Interledger.js、JerryScript、Mocha、Moment.js、 Node-RED和webpack。

其中的JerryScript项目是一个用于物联网设备的轻量级JavaScript引擎，该项目由Samsung贡献。Samsung软件研发中心副总裁Youngyoon Kim说，Samsung展示了JerryScript如何用于物联网上的高效设备，例如智能手表和其它的可穿戴设备。

Kim说：“我们邀请具有任何教育背景和行业经验的JavaScript开发人员加入我们的JavaScript和物联网生态系统。”

Node.js基金会的社区经理Mikeal Rogers告诉InfoQ，为与JS基金会紧密结合，Node.js基金会正在审视一些合并效应和技术机会。作为Linux基金会的开发人员所关注技术组合的组成部分，这些合并效应和技术机会将允许Node.js基金会和新JS基金会间的跨平台协作。

“使Node.js的开发及其它的相关模块能被广泛地采用并加速，这是Node.js基金的持续重点所在。”Rogers说，“Node.js已经成为一种被普遍采用的技术，更为重要的是JS基金能使该技术进一步地发展和演进，继续领先于市场增长的需求。”

从Hacker News来看，JavaScript社区对此新闻的反应不一。一些人质疑JS基金会的建立是否能降低JavaScript空间中的碎片化问题。但是对于这种碎片化问题是否是一件坏事，社区并未明确形成一致意见。

详见：https://news.ycombinator.com/item?id=12733445

此外，还出现了一些对基金会的创始成员的担心，就是“他们对开发并推进那些最值得被广泛采用的、最好的开源工具漠不关心”。

详见：https://news.ycombinator.com/item?id=12734275

对此担心，Lodash的创建者John-David Dalton是如此回应的：“就我的经验而言，基金会是一个相当好的、不对项目指手画脚的、非营利的组织。在Lodash开发的早期，我就找到并志愿加入Dojo基金会……最终Dojo基金会和jQuery基金会合并了。这非常棒！不管叫什么名字，基金会被证实是有价值的。”

本文翻译已获授权，原文链接：

https://www.infoq.com/news/2016/10/linux-foundation-javascript

本文译者：Rays

近日，Elastic在官方博客中宣布，Elasticsearch 5.0正式发布。该版本基于Lucene 6.2.0，已经在Elastic Cloud上完成了部署。据称，这是迄今为止最快、最安全、最易用的版本。

Elasticsearch 5.0带来了许多增强功能和新特性，主要包括：

• 索引性能：得益于多项改进，其中包括更好的数值型数据结构，索引吞吐量大幅提升。根据应用场景的不同，索引吞吐量提升在25%到80%之间。
• Ingest节点：向Elasticsearch添加数据更简单了。Logstash是一个强大的工具，而一些较小的用户只需要过滤器，不需要它所提供的众多路由选项。因此，Elastic将一些最流行的Logstash过滤器（如grok、split）直接在Elasticsearch中实现为处理器。多个处理器可以组合成一个管道，在索引时应用到文档上。
• Painless脚本：Elasticsearch中很多地方用到了脚本，而出于安全考虑，脚本在默认情况下是禁用的，这令人相当失望。为此，Elastic开发了一种新的脚本语言Painless。该语言更快、更安全，而且默认是启用的。不仅如此，它的执行速度是Groovy的4倍，而且正在变得更快。Painless已经成为默认脚本语言，而Groovy、Javascript和Python都遭到弃用。要了解有关这门新语言的更多信息，请参照：https://www.elastic.co/blog/painless-a-new-scripting-language
• 新数据结构：Lucene 6带来了一个新的Points 数据结构K-D树，用于存储数值型和地理位置字段，彻底改变了数值型值的索引和搜索方式。基准测试表明，Points将查询速度提升了36%，将索引速度提升了71%，而占用的磁盘和内存空间分别减少了66%和85%。参见“在5.0中搜索数值”：https://www.elastic.co/blog/searching-numb3rs-in-5.0
• 搜索和聚合：借助即时聚合，Kibana图表生成速度显著提升。Elastic用一年的时间对搜索API进行了重构，Elasticsearch现在可以更巧妙地执行范围查询，只针对已经发生变化的索引重新计算聚合，而不是针对每个查询从头开始重新计算。在搜索方面，默认的相关性计算已经由TF/IDF换成了更先进的BM25。补全建议程序经过了完全重写，将已删除的文档也考虑了进来。
• 更友好：Elasticsearch 5.0更安全、更易用。他们采用了“尽早提示”的方法。如果出现了问题，则新版本会及早给出提示。例如，Elasticsearch 5.0会严格验证设置。如果它不能识别某项设置的值，就会给出提示和建议。不仅如此，集群和索引设置现在可以通过null进行解除。此外，还有其他的一些改进，例如，rollover和shrink API启用了一种新的模式来管理基于时间的索引，引入新的cluster-allocation-explain API，简化索引创建。
• 弹性：Elasticsearch分布式模型的每一部分都被分解、重构和简化，提升了可靠性。集群状态更新现在会等待集群中的所有节点确认。如果一个“复制片（replica shard）”被“主片（primary）”标记为失败，则主片会等待“主节点（master）”的响应。索引现在使用数据路径中的UUID，而不是索引名，避免了命名冲突。另外，Elasticsearch现在进行启动检查，确保系统配置没有问题。配置比较麻烦，但如果只是试用，开发人员也可以选择localhost-only模式，避免繁琐的配置。另外，新版本还增加了断路器及其他一些软限制，限制请求使用的内存大小，保护集群免受恶意用户攻击。

此外，该版本还提供了一个底层的Java REST/HTTP客户端，可以用于监听、日志记录、请求轮询、故障节点重试等。它使用Java 7，将依赖降到了最低，比Transport客户端的依赖冲突少。而在基准测试中，它的性能并不输于Transport客户端。不过，这是一个底层客户端，目前还没有提供任何查询构建器或辅助器。它的输入参数和输出结果都是JSON。

需要注意的是，该版本引入了许多破坏性更改，好在他们提供了一个迁移辅助插件，可以帮助开发人员从Elasticsearch 2.3.x/2.4.x迁移到Elasticsearch 5.0。如果是从更早的Elasticsearch版本向最新的5.0版本迁移，则请查阅升级文档：

https://www.elastic.co/guide/en/elasticsearch/reference/5.0/setup-upgrade.html

本文翻译已获授权，原文链接：

本文译者：谢丽

Rust的核心团队敲定了Rust语言将在接下来的一年何去何从的规划提案：

https://github.com/aturon/rfcs/blob/roadmap-2017/text/0000-roadmap-2017.md

一定程度上基于2016年在Rust用户中的调查结果，Rust2017规划方案优先考虑在不牺牲速度和可靠性的前提下提升Rust的生产力。

值得一提的是，Rust2016调查暴露出了一些阻碍Rust接受度提升的问题，例如，Rust的学习曲线、程序库和集成开发环境的缺乏、语言成熟度的担忧以及编译性能。Rust2017规划方案重点强调了这些问题，并提供了一份详细的改进方案。

学习曲线

在Rust2016调查中，有近四分之一反馈者提到Rust的学习曲线。这可能一定程度上跟Rust基于所有权概念的非主流的内存管理模型有关。Rust团队制定的改进策略包括：改进文档，改进语言诊断系统和语言功能，改进工具。

工具

在工具方面，Rust团队将会改进“编辑－编译－调试”循环，并提供一个集成开发环境。在提升“编辑－编译－调试”循环方面，Rust团队已经完成了一些工作。他们提出了一种中间代码（MIR）来帮助编译Rust源代码，并且提供了一种更简单的类型检查和转换的表示方法。

他们提供了增量编译功能，并且已经处于alpha测试阶段。此外，Rust目前的调试版本“运行得非常慢”，而Rust的发行版本“构建得非常慢”。Rust团队将试图在这两者间取舍一个更平衡的方案。

Rust生态

Rust生态成熟度是Rust团队提高Rust生产力的另外一个关注点。一方面，Rust生态需要提供开发高质量工具箱的方法，包括信号质量预测、更好地支持持续集成、在特定工具上支持API审核等等。另外，Rust生态系统应该成长并提供一套基本成熟的能够帮助完成基础任务的工具箱，特别是在服务器端的并发编程（Concurrent）、异步编程（Async）、并行编程（Parallel）方面。

互操作性

在生产环境使用Rust经常需要它能够和已有的构建系统集成，并且能够和C++代码交互。综合这两方面的考量，Rust团队计划让Rust能够更简单地与现有系统集成。特别是，在Rust中使用C++库应该不会比直接在C++中使用C++库复杂太多。

以上只是Rust2017规划方案的概要，如果想知道更多Rust技术规划的细节，包括在缺陷和替代方案方面的讨论以及尚未解决的问题等，可以参考RFC文档：

https://github.com/aturon/rfcs/blob/roadmap-2017/text/0000-roadmap-2017.md

本文翻译已获授权，原文链接：

https://www.infoq.com/news/2016/10/2017-rust-roadmap

本文译者：张健欣

搜罗最 In 最潮的极客玩物，关注技术人8小时工作以外的时间，你值得更好的品质生活。极客官舍，为极致和美好付费。

    关注 微文阅读推荐