[转载]是时候升级你的命令行了

[egen]

发现一篇好文：是时候升级你的命令行了 里面列举了几个常用的命令行升级版，可以提高不少工作效率 https://riboseyim.github.io/2018/09/03/Linux-Commands-New/

前面是新命令，后面是被替代的命令，具体安装和用法见文章的内容

bat > cat
prettyping > ping
fzf > ctrl+r
htop > top
diff-so-fancy > diff
fd > find
ncdu > du
tldr > man
ack || ag > grep
jq > grep et al

个人最喜欢的是 diff-so-fancy，比传统的 diff 效率提高很多

[Tyanboot]

@henglinli so，一方面嫌弃 rust 没有用 llvm 的 coroutine，另一方面又嫌弃 rust 依赖 llvm 而不能完全自举。

这难道就是失传已久的“我 杠 我 自 己”？

[widewing]

这些工具 rhel7 上自带吗？没有？不好意思。。

[GGGG430]

恕我直言，你列举的替换工具都是 centos 不自带的，我那么多服务器也就用不上（运维不会给你装这些的）

[fenglangjuxu]

谢谢分享.

[Sparetire]

按照某些人的逻辑，这世界上大部分语言都不是完整的语言，因为它们不能自举。。然而完整要怎么定义呢？我觉得还是说是否图灵完备比较好，不然自己发明个词就可以把其他语言批判一番，这不好

[carlclone]

@mantianyu 兄台太逗了

[henglinli]

@Tyanboot 我是想转移注意力。我更关心有没有其他语言使用了 llvm 的 coroutine，所以转话题到 llvm 了。我担心它用到 llvm 的 cortoutine 的话，就更难做到完全自举起了。让你理解出嫌弃的意思，表示抱歉。我尽量倾向使用不带感情色彩的词来讨论。

@trait 1，如果不是 @Kilerd 后面有接着继续讨论，只说“基本都是 rust 写的，Rust 大法好”的话，我理解的就是他在“吹“。2，我任然坚持不能完全自举起的语言不完整的观点。太依赖 llvm 会导致 llvm 变动影响 rust 的发展。没记错的话，rust 曾经是有自己的 llvm 分支的，原因是 llvm 不接受 rust 的变更请求。我相信如果 Mozilla 不放弃 rust 的话，会有人让他完全自举的。题外话：很多语言后端都有 llvm，这个现象很明显，这个现象令人担忧，一家独大肯定不是好事。最后，不赞同他人的观点可以反驳，但是带有明显感情色彩的词语尽量少用。

@minami 我确实没有系统的学过 rust，只是了解了一些我感兴趣的部分；个人发言只代表个人观点，你总结的不错；其他人都在或多或少的反驳我，你没有。

@Sparetire OK。rust 其实已经做到自举，这个我知道，其他参与讨论我 @到的应该也知道。我加一个”完全“在”自举“前面我相信他们理解为 rust 编译器本身不是全部由 rust 实现并编译的这个意思。正因为我看好 rust 才希望 rust 能做到这点，至于你理解到我在批判 rust，可能是我表达方式和你不同，造成你理解误差。

最后，我觉得我是有问题的：我以为 @Kilerd 在”乱喊“ 666，当然后来他参加讨论，让我重新认识到他不是在“乱喊”。

[trait]

@henglinli
1. 列出的 cli 基本上都是 rust 写的，在这种当前语境下调侃式的大法好就是吹，你的“吹”底线未免太低。后面拖出来的 llvm 更是莫名其妙，llvm ir 后面还有一层 machine code，是不是还要应该感谢硬件？
2. 搞这么久编译器开发，第一次听说所谓的完全自举这种不明所以的“概念”，不管是 rust 到 llvm ir 还是其他语言到 machine code 甚至是 binary，都不过是透明封装，你这种近乎偏执的追根溯源没有任何意义。rust-llvm 只是是 llvm 的 wrapper，llvm 则保持同步，rust 工作组有在 llvm 活跃的成员，基本上遇到的问题都会第一时间向上游报告。所谓一家独大，llvm rust 都是不受商业公司控制的社区项目，llvm 作为现代编译器框架“最佳”实践，除了前几年的 gcc，很难找出比 llvm 更好的优化，从未有过 llvm 威胁下游项目作出妥协。情绪化用词是表达对“完全自举”这种民科说法的震惊

[Kilerd]

行吧，居然把锅甩到我这里来了。
这段时间很火的，或者说「突然间井喷式地出现在公众眼中」的命令行替代品大部分都是 Rust 写的，我自己已经用上的有以下这些：
- bat (cat)
- exa (ls)
- fd (find)
- Rust 官方文档中教学模式的 grep

这些命令行无一不体现了 Rust 的「 blazingly fast 」特点，也证明了 Rust 比较适合于做基础服务。

在懂的人里面，这无疑在「暗示」吹捧 Rust， 那么我说个「 Rust 大法好」完全没啥问题吧，我也不是在其他语言出现的地方吹捧 Rust。


----

回到 LLVM 的问题上，我觉得 Rust 选用 LLVM 是有理由的，LLVM 极大地降低了在语言初期阶段过多设计 LIR 层面的设计和优化，利用 LLVM 可以得到其极其方便的跨平台，跨框架的编译优点，我觉得这也是 Rust 能做得那么好的原因之一「把仅有的、有限的精力放在该关注的地方」。

目前来说 Rust 只分析到了 MIR 层面，最大的 feature 就是利用 miri 库来实现 NLL 的分析，这已经极大的改善 Rust 的编程体验了。当然了，我也不是开发组的成员，但是我认为到了 MIR 都不能满足 Rust 的时候，再重新考虑制作一个 MIR2LIR 的库又怎样呢。

----
再回到 LLVM 的 coroutine 问题，Rust 从一开始标准库中带有异步库，到后来的移除，再到后来的「由社区自行设计的决定」，再到现在的「 async / await 语法糖引入」都是慎重选择的。当然了，也并没有说 到底谁的设计更好，只能说各自面向的群体不一样，导致取舍不一样把。

----

不好意思，我没听说过「完全自举」这个说法，能用 Rust 写出 Rust 编译器，然后用 这个新的编译器成功编译出新的 Rust，那么就是自举了。