这是一个创建于 2197 天前的主题，其中的信息可能已经有所发展或是发生改变。
发现一篇好文：是时候升级你的命令行了 里面列举了几个常用的命令行升级版，可以提高不少工作效率 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 效率提高很多
 |
1
trait 2018-11-04 16:08:30 +08:00 via iPhone
ripgrep 比那几个都好儿
|
 |
2
Kilerd 2018-11-04 17:19:13 +08:00
基本都是 rust 写的，Rust 大法好
|
|
4
trait 2018-11-04 17:56:30 +08:00
@henglinli 再从 0 造一个编译框架？显然没有必要，llvm 这么多年发展差不多要成为最佳实践了，swift 等语言都是拿 llvm 作后端
|
 |
6
mantianyu 2018-11-04 18:13:19 +08:00
好多命令不如以前敲起来高效. 尤其是 diff-so-fancy 使用时也要敲这么长的命令吗...
|
 |
7
sticnarf 2018-11-04 18:23:39 +08:00 via Android
@henglinli Rust 的革新之处和 LLVM 完全没有关系。要是 Rust 人手够，要什么 LLVM，像 Go 一样连 libc 的不依赖了不更好。Rust 撞 LLVM 的 Bug 也不少了。
|
|
8
sticnarf 2018-11-04 18:27:25 +08:00 via Android
当然也不能否认 LLVM 的贡献。没有 LLVM，Rust 现在在哪里都不知道呢
|
 |
9
dazhangpan 2018-11-04 18:45:03 +08:00
随便推荐一个 autojump 极大改善 cd 效率
|
 |
10
omph 2018-11-04 18:51:02 +08:00
prettyping 在 xterm 中的绘制还是有些问题
|
 |
11
henglinli 2018-11-04 18:53:25 +08:00
@sticnarf 我怕知道 rust 好而忘了 llvm 的情况发生，说得有点过了。既然都开头了，我想了解下：rust 目前有没有实现基于 llvm coroutine 的 coroutine （好别扭，有基于 llvm coroutine 的 future 等就更好了）。没记错的话，golang 1.6 左右才完全 bootstrap 的，不知道 rust 有没有这条 roadmap。
|
|
12
sticnarf 2018-11-04 19:00:16 +08:00 via Android
@henglinli Rust 没有用 LLVM 的 coroutine，现在是自己实现的。（虽然 async/await 在 stable 上还用不了）
|
|
14
trait 2018-11-04 20:21:59 +08:00
@henglinli 1. 这些命令大多是 rust 写的，不存在什么吹不吹
2. llvm 只是负责生成代码，跟 rust 语言特性无关 |
 |
15
chengluyu 2018-11-04 20:23:52 +08:00
@henglinli
不要避重就轻嘛，coroutine 这么成熟的东西造出来只是时间问题，Rust 最有意义的是它的类型系统。 |
|
16
Kilerd 2018-11-04 20:46:53 +08:00
@henglinli Rust 在 RFC 阶段已经有了自己的 async await 系统，而且目前已经快实现完成了。
基于 LLVM 是可以获得很多来自 LLVM 的优点和便捷，可以把更多的精力放在「如何设计一门好的语言」上 |
|
17
henglinli 2018-11-04 23:42:53 +08:00
@trait 1，我根本不关心这些新的命令如何如何。2，这样理解，你觉得好就好，我无话可说。
@chengluyu 隐约感觉到自己有点“政治不正确”了，但是我没有必要学习 rust 后再来和你们讨论 rust 吧。coroutine 成熟的只是概念，我知道早就有 rust 的 coroutine 实现了。我觉得 rust 最有意义的是他的” memory safe “。根据 @Kilerd 的说法，还没用上 llvm 的 coroutine。用到 llvm 的特性越多，就越难摆脱 llvm 了。只要是懂 rust 的人吹 rust 就好。 我始终认为，不能完全 bootstrap 的语言不是完整的语言。当然不完整的语言也有了解它必要。当 TOR 迁移到 rust 基本完成的时候，差不多是系统学习 rust 的时候。 |
3
|
20
trait 2018-11-05 00:12:40 +08:00 via iPhone
@henglinli 1. 所以你所谓的站着 666 不腰疼是个什么鬼？有人在这儿吹了 rust ？
2. swift haskell julia python 等语言都用部分或全部依赖于 llvm，他们各自的特性跟 llvm 有什么关系？先搞清 bootstrapped language 是什么意思好么，按你的奇葩逻辑评论这些语言是不是还要带上厂商提供的硬件指令集才算完整？ |
 |
21
Tyanboot 2018-11-05 00:31:52 +08:00 via Android
|
 |
22
widewing 2018-11-05 01:09:17 +08:00 via Android
这些工具 rhel7 上自带吗？没有？不好意思。。
|
 |
23
GGGG430 2018-11-05 08:37:57 +08:00 via iPhone
恕我直言，你列举的替换工具都是 centos 不自带的，我那么多服务器也就用不上（运维不会给你装这些的）
|
 |
24
fenglangjuxu 2018-11-05 09:48:21 +08:00
谢谢分享.
|
 |
25
Sparetire 2018-11-05 13:47:20 +08:00 via Android
按照某些人的逻辑，这世界上大部分语言都不是完整的语言，因为它们不能自举。。然而完整要怎么定义呢？我觉得还是说是否图灵完备比较好，不然自己发明个词就可以把其他语言批判一番，这不好
|
|
27
henglinli 2018-11-06 01:15:21 +08:00
@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，当然后来他参加讨论，让我重新认识到他不是在“乱喊”。 |
|
28
trait 2018-11-06 01:59:29 +08:00 via iPhone
@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 威胁下游项目作出妥协。情绪化用词是表达对“完全自举”这种民科说法的震惊 |
|
29
Kilerd 2018-11-06 10:26:08 +08:00
行吧，居然把锅甩到我这里来了。
这段时间很火的，或者说「突然间井喷式地出现在公众眼中」的命令行替代品大部分都是 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，那么就是自举了。 |
Select Language