分享 分享一下我用 Rust 写的 CLI 版 Anyshortcut 以及使用 Rust 半年的感想
Anyshortcut是我发布于 2017 年 12 月的 Chrome/Firefox 效率插件，一直坚持订阅制收费， 到目前为止注册用户将近 1000 位，使用信用卡订阅用户接近 3% 吧。
大半年前接触到 Rust，被这门语言深深折服，于是从官方文档开始学习 Rust，入门之后写了一个Anyshortcut CLI版。
项目地址
https://github.com/anyshortcut/anyshortcut-cli
自认为这个项目很适合 Rust 初学者学习。
命令行的 Anyshortcut 可以干什么？
因为 Anyshortcut 的快捷键是可以同步的，对于 CLI 程序是通过 Access token 来访问后端 API 来同步快捷键的。Access token 可以在官网用户中心找到。
用 Access token 登录之后即可把所有快捷键同步下来，然后可以使用命令行快速打开网页。
比如，我给https://www.google.com 绑定了快捷键G，那就可以输入as g快速用默认浏览器打开 Google。
$ as g
Url: https://www.google.com/
其他的混合快捷键、二级快捷键也是类似，就不再介绍了。
当然这里的命令as是anyshortcut的别名，要不然名字太长了，根本就算不上效率工具了。
alias as=$(which anyshortcut)
怎么安装
- 如果你是 Rust 开发者，很简单，用cargo install就行。
cargo install anyshortcut
- 当然我也提交了 Homebrew，但是因为 GitHub repository not notable enough (<30 forks, <30 watchers and <75 stars) 的原因暂时没有被 merge，希望以后能达到这个要求。Merge 之后就可以通过 brew 安装了。
brew install anyshortcut
使用 Rust 半年之后的感想
申明：除了 Rust 之外我个人熟悉的编程语言只有 C++ 2003, Java, Python, Javascript, Groovy，我并没有研究过各种编程语言， 甚至 Ruby、Go、Swift、Kotlin、Scala，Haskell 等我都一律没有去学过，所以这些只能算比较浅显的感想。
相识恨晚。 其实我大概 16 年的时候才知道的 Rust，当时认识几个不错的程序员在写一些 Rust 的项目，不过我还不以为然，以为又是一门什么赚噱头的新语言，就没有太多的关注它。直到今年初机缘巧合才真正的激发我学 Rust 的强烈兴趣。目前我也看到了好几位和我一样学了 Rust 之后发表Rust 真香的赞叹！
概念很多，门槛很高。 Rust 是一门对标 C/C++ 的系统级编程语言，它在既能处理好内存安全、线程安全的这些问题的同时也支持各种现代编程语言的特性，比如函数式、错误处理、并发处理、依赖管理等。写起来还是比较优雅的。当然 Rust 没有自动 GC，所以它引入了很多 Rust 独有的新概念，比如生命周期、所有权、借用等让初学者非常不适应。
优秀的依赖管理和文档生成工具。 Rust 的 Cargo 绝对是我用过的所有语言里面最好的依赖管理工具，非常省心人性化。Cargo 提供的文档生成体验也很棒，这才是现代化的编程语言应该具有的。
越写越爱不释手。 写 Rust 最难过的一关就是编译器，你会被它折磨的心累，太严格太死板了，稍微不对就会编译不过。当然 Rust 官方也在优化这一点，比如 NLL。但是只要你过了编译器这一关，编译没问题，线上运行绝对没有问题 (Unsafe 的代码、内存泄漏或溢出除外）,不像 Java 编译过了，线上还有可能出现 NPE 啊啥的。编译成功之后非常放心，几乎不需要花时间去线上复现解决那些诡异的 bug。
国内很冷门，但前景很看好。 Rust 在国内确实太冷门了，目前社区也很少，Rust 相关的会议更是寥寥无几，招聘 Rust 的职位非常少，除了蚂蚁金服、今日头条、Pingcap 和区块链公司，其他公司的职位几乎没有。另外 Rust 也还缺少明星级的项目，这些都需要时间去沉淀吧。目前国内学 Rust 的基本上都是出于情怀和对这门语言的喜爱。Rust 不管是在系统级编程、网络编程、并发编程、嵌入式、WebAssembly 等方面都在发力，德国越来越多的公司在使用 Rust 应用于他们的工业 4.0，甩我们多少条街？Github 发布的 2018 年终总结提到 Rust 是增长速度最快的编程语言第五位。我学 Rust 也是出于情怀，但是我还是相信 Rust 在全世界的前景还是非常光明的（没有特指中国）。
另外我在 reddit/rust 也发了一条介绍性的帖子，upvote 数还可以，感兴趣的可以看看。 https://www.reddit.com/r/rust/comments/9ptvwq/show_reddit_a_rust_cli_tool_to_help_you_launch/
Cargo 的核心团队里有 Yehuda Katz（前 Ruby on Rails 核心团队成员），吸收了 Ruby 社区依赖管理的成功经验，所以依赖管理是同类语言里最好的。反面例子就是 Go 了，最近才由官方推出 Dep 终结混乱。
能高效的解决问题的工具就是好工具，不用太在意用的人多不多，有时用的人少反而是自己的秘密武器。
谢谢，长知识了。果然优秀的人到哪都会一直优秀，原来那些我听过甚至用过的工具都由这个哥们开发或参与开发，确实让人敬佩。
哈哈哈，Anyshortcut 确实是一款比较小众极客的产品，一般人用不到，采用订阅制收费仅仅是一种对 SaaS 的尝试，并没有刻意在乎多少人会用。
I split my time between Ruby, JavaScript (mostly with TypeScript) and Rust, with occasional Java and devops work. Of those, JavaScript (with TypeScript) is my predominant language at the moment, but the mix changes pretty often. Skylight's stack is Rust and Ruby for the agent, Rails for the backend, Java for our data processing pipeline (essentially a custom data store) and Ember for virtually the entire front end. The graphs in Skylight are Ember components written in d3.
I still think that Rails is a great choice for most web apps, since (to this day) it provides an extremely productive baseline for building account management and working with third-party integrations, which turn out to be a surprising percentage of the total code (and an even higher percentage of backend code changes) in even an ambitious project like Skylight.
I also think it's reasonable to use something like Java or Rust for any heavy data-crunching your app might do, but I think people overestimate which aspects of their application are truly performance and efficiency critical.
-- Yehuda Katz, talking about his language chosen in routine work
另外，Cargo 其实已经超出了依赖管理的范畴了，它应该是一种工作流程管理器（WorkFlow Tool）。它之所以好，是因为设计伊始就从更高的角度来审视 Rust 程序员的日常工作流程，而依赖管理仅仅是其中的一个环节而已。最近出现的语言中，比如 Elixir 的 mix 也是类似的理念和设计，不过 Elixir 更年轻，还有一些地方需要向 Rust 学习的。
关于 Cargo 的设计理念，Yehuda 有专门撰文介绍：https://blog.rust-lang.org/2016/05/05/cargo-pillars.html
Rei
回复
貌似又搞了个 vgo https://blog.golang.org/versioning-proposal要取代 dep...
使用 Rust 将解析日志的速度提高了 230 倍
该文章是《The Ruby Way》的作者 André Arko 写的，同时他也是 Ruby 包管理器 Bunlder 的 No.1 贡献者，以及 Rubygems.org 的维护者。
所以，他在维护 Rubygems.org 的过程中，遇到最让他头疼的事情就是对日志的处理。Rubygems 每天有 4000 到 25000 个请求，磁盘每天可以产生 500GiB 的日志。他们尝试了一些日志的托管产品，但是这些产品也只能为他们保留 1 个小时以内的日志数据。
大概一年前，他把完整的日志进行了压缩，放到了 s3 上面，存储成本大概是每个月 3.5 美刀。但是有很多他感兴趣的统计数据被「埋葬」在了 S3 上面。因为 S3 的 gzipped JSON 流很难查询数据。这些统计数据有利于提供 Ruby 生态系统状态的重要信息。
后来利用 aws 的 Glue 功能，可以运行基于 spark 脚本的 hadoop 集群，他写了一个统计脚本，但是费用上升到了每月 1000 刀。
后来，也不知道是什么原因，让他想到了 Rust。
事实证明，Rust 满足了他的需求。Serde Json 库，让他可以在 2 秒内将 1GB 的 JSON 反序列化为 Rust 数据类型。并且使用 nom 来解析日志，可以在 3 分钟内解析 1GB 的日志文件，作者说，用 Python 和 Glue 在 30 分钟内解析完日志，他就觉得了不起了。
但是作者又仔细阅读了 nom 的文档，发现了一句「有时候，nom 几乎和 regex 一样快」，这句话给了他灵感，他又用 regex 重写了解析代码，性能又提高了 3 倍。至少比 spark 中使用 python 解析快 30 倍。但是他把这个 Rust 程序的性能又多牛逼的事情告诉 @ReinH （他的朋友，Rust 的贡献者之一，比他更了解 Rust）的时候，ReinH 说，怎么这么慢？你这个程序必须得优化。
他不清楚他的朋友是不是跟他开玩笑，但是他继续对 Rust 进行研究，然后他发现了—release 模式，在使用 release 模式编译代码之后，突然发现：他可以在 8 秒内把 1GB 的文件解析完。以下是处理速度的一个对比记录：
~525 records/second/cpu in Python on AWS Glue 50,534 records/second/cpu in Rust with nom 121,153 records/second/cpu in Rust with regex + release
但他没满足，继续使用 rayon 对程序并行化处理日志，最终的程序，在 8 核机器上快了 100 倍，在单核上跑，快 230 倍。现在的 1GB 的日志文件处理需要 6.4s。
151,441 records/second/cpu in Rust with regex + release+ rayon
最后如何部署是个问题。
他尝试了一些方案之后，最后发现了 aws Lambda，它有一个免费策略：每个月 400,000s。而作者处理 500GB 日志，只需要 3000 多 s。于是他就快乐地使用了 aws Lambda 功能。
源码 : https://github.com/rubytogether/kirby
原文：https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-with-rust/
转载自：Rust 每日新闻