Looks neat, but again, 99% of those utils I've never ever thought "this shit too slow" or "UX sucks". Replacing for the sake of replacing I'm not too keen on.
They also have the benefit of being in a memory safe language and being cross-platform. Rust does actually have some advantages when it comes to making secure & stable tooling.
This aims to be a drop-in replacement for GNU coreutils and might actually serve to increase security, stability, & speed across the system as a ton of stuff rely on coreutils.
Now it's still not complete, so you can't just replace everything but I've actually noticed an improvement in my system with hybrid.
I know, but coreutils also literally never broke on me as they are. To me, the whole point of coreutils is that they're just... there. I'll leave the decision to change bundled tooling to distro maintainers.
I'll also be perfectly honest: from a developer standpoint, end-users caring about the language a tool was developed with is, in the end, a pretty weird concept to me. Memory safety and cross platform compilation is DX stuff. Nothing tells you as a user that the thing you're using isn't sprinkling unsafe everywhere, in the end... The application itself doing what it advertises is what I'd expect most users to care about. Especially for stuff as old and relatively stable as most coreutils.
Ah, except Electron. Fuck most Electron apps.
If you go to the uutils repo you can see that it's making proper use of fuzzing, test, etc. and only makes use of unsafe in necessary areas.
Uutils is also more consistent with modern standards thanks to clap & uniform design, has out of the box selinux support, etc.
if you use a reference in unsafe code, it will still be checked.
Also many distros are already packaging uutils do to it "growing into remarkably robust shape", it's just not ready to completely replace coreutils quite yet and so it's not up for consideration by distros to ditch coreutils until it's at least at parity.
(That's why I make use of hybrid and not outright replacing everything).
The point is not the language, it's how the project is making use of the language and uutils is doing a lot right.
My point was intended to be more generic than just uutils though. Agreed that this specific project looks interesting.
And yes, I know the unsafe keyword is not inherently unsafe to use, but it's also, in practice, one of the few potential footguns of the language, and is easy to abuse and get wrong. It'll raise a few eyebrows in PRs and you'll be expected to have both good reasons and a good test coverage at the very minimum lol. It's a good red flag, if you do end up with runtime memory issues, that it's probably happening in that block, but past this, you're still basically foregoing some safety for convenience. And people fail. Often.
Utilities built in Rust have a higher potential for better security, all else being equal.
Uhhhhh, they do?
I don't really thing the security 'guarantees' of rust matter that much.
I think it's a better language to work in than C or C++, though. That's not a reason to change utilities now, but a larger Rust ecosystem is always better in my humble opinion.
Yes thatβs the major selling point in the Rust language in my opinion. Memory safety. Most of the security issues you hear about are because of mismanaged memory, specifically buffer overflows. My understanding is that Rust reduces risk of those by catching them at compile time.
Because Rust is better, hurr-durr.
Forgor the /s
Turns out Lemmy isn't better at understanding sarcasm than Reddit lol.
If the current tools work fine, have decades of historic support and battle testing, and the alternatives offer little to no net benefit, uhh, why?
But rust
Aye, I can't argue with that
Is Rust Web Scale?
Battle hardened > new
Unless the new has a killer feature set worth the trade off in potential bugs
I think that's fair.
Eventually, the Rust-alternatives will be battle-hardened too and we can simply choose what suits us best.
It's a good time for software, honestly.
Agreed that competition only helps us users
Are you still using bash?
Like many others, I don't replace old tools with new ones, simply because it is written in Rust. For example, fzf is a very novel and useful tool that's written in Go. (FYI: Fzf has a Rust alternative called skim). I'm going to restrict the rest of the post to the context of this thread - Rust CLI/TUI programs that I like. But by no means are they the only new ones I like, or always a replacement for the old ones.
fd and ripgrep (rg) have 2 things in common that give them edge over their older counterparts. First is that both are extremely fast compared to their predecessors. Second is that both support a modern (perl-compatible) version of regex syntax that many programming languages support.
Zellij is a terminal multiplexer like Tmux. However, Zellij IMO has one huge advantage over Tmux and screen - you don't need to take a tutorial or read a user guide just to get started. Everything is discoverable and intuitive. Zellij has the potential to replace TMux as the dominant terminal multiplexer in the near future.
You may find zoxide, atuin and starship as good extensions to your terminal experience, depending on your tastes. Zoxide is a smart directory changer (alt for cd) with good integration all around - with a lot of shells, alternatives (data import), editors (emacs, nvim, etc), file browsers (ranger, nnn, etc) and even mail client (aerc). Atuin replaces the history part of GNU Readline. But lately, it has started gaining features not found in readline, like encrypted history and cross-device history sync. Starship may be a bit fancy for shell prompts - but I find its configuration format to be simpler than the old method. It also supports several shells giving you a uniform experience across shells.
GPG-TUI is a TUI frontend to GnuPG. It's useful simply because the GnuPG UI is terrible. Meanwhile, Sequoia PGP is a tool that aims to replace GnuPG altogether. It has some lofty ambitions and has forced the OpenPGP ecosystem to advance a bit. Some of their innovations aim to solve the drawbacks of old OpenPGP - like lack of PKI (instead of just WoT) and Perfect forward secrecy in certain modes. Its defaults are also more sane and modern compared to GnuPG.
Git-UI (Rust) and LazyGit (Go) are TUI frontends for Git - they have no alternatives. I can recommend either of them if you are a heavy user of git - especially interactive staging and interactive rebasing. Meanwhile, git-interactive-rebase-tool is a tool specifically designed to manage interactive rebases.
If you are into coding, you may find Tokei useful. It is tool for counting Lines of code (LoC) in your projects, segregated by language. Hyperfine, from the developer of fd, is used to benchmark applications over several runs, with a lot of configuration options. Bat is a terminal pager, again from the developer of fd. It supports syntax highlighting. I often find uses for that. I'm not aware of another tool with the exact same functionality.
Finally, nushell is showing a lot of promise as a shell with more modern features. It extends the structured data paradigm from powershell.
Forgot to mention stacked-git (stg). This is a tool to deal with patch stacks - much like the age old quilt tool often used by kernel hackers. Unlike quilt, stg uses git to manage a stack of patches. This tool was originally written in Python. It was recently rewritten in Rust by the same team.
Having used stg, it's like having multiple staging indexes in git. This allows you to craft a good commit history like the one you get from using interactive rebasing. Unlike interactive rebasing, you don't have to wait till finishing the feature, in order to achieve that result. If you are a git user and haven't given stg a try yet, I strongly recommend you do. It's a nice tool to have in your development tool chest.
Note that skim performs worse than fzf. There's a new matcher in Rust called nucleo which is faster, but it currently doesn't have a cli and can only be used inside Helix editor (hx)
nu is probably the best shell for ad-hoc data processing, handling all my daily needs in one expression.
fd and rg have another thing in common, that they're both 50% shorter than their traditional alternatives /s
nu is probably the best shell for ad-hoc data processing, handling all my daily needs in one expression.
I am really struggling with this, I heard about nu shell some time ago, but the fact that you had to learn some form of new language made me reluctant to actually try it.
As a fisher user I want to have sane usable defaults, without having to learn just another programming language for a "tool".
What am I missing?
It kinda fills a niche.
I use fish for simple command pipelines as well. But traditional shells are not as good when I need to do anything "structured", because they treats almost any value as a string and don't have anonymous functions. The first problem means that you have to parse a string again and again to do anything useful, the second means that when both pipe and xargs fails you are doomed.
Nu solves both of the big problems that matters when you want to do rather complex but ad-hoc processing of data. And with a rather principled design, nu is very easy to learn (fish is already way better than something POSIX like bash though).
Personally another important reason is that I have a Windows machine at work and nushell is much easier than pwsh.
Btw fish is also going to be a "tool in rust" soon :)
fd is pretty cool. It offers a good simplification over find's syntax. find -name "*file*" vs fd file. rg I don't use often except for colorized output. A lot of Nvim plugins also prefer to use ripgrep over grep.
Thanks for your comprehensive comment!
Just to add - gitui doesn't (yet) have the commit signing, so for commiting stuff you still have to use command line, but other features are pretty useful.
Yes. The only things I use regularly that aren't aliased to or replaced by a rust-built tool are mkdir, ln, and rsync.
cd: zoxide
ls: eza
cat: bat
grep: ripgrep
find: fd
sed: sd
du: dust
top/htop: btm
vi: helix
tmux: zellij (or wezterm mux)
diff: delta
ps: procs
Probably some others I'm forgetting
I have a strong bias for staying with tools that are installed by default. After this many years working with new systems of my own, containers, and systems where I'm not root, the added value of an alternativehas to be quite high for me to switch a core utility.
Thay said, I've found fd, ripgrep, and helix to meet that criteria. The others, not so much; they either don't improve upon or add functionality that's not available, or simply add eye candy. Gaining pretty colors is nice, but not worth losing familiarity with ubiquitous tools.
git-delta is an exception where the syntax highlighting can make a functional difference in code diffs. Not so much that I think about installing it, or using it outside of indirect VCS configuration, but it is a good example of using style for more than just eye candy. I prefer difftastic, but they do much the same.
While it's not a replacement for an existing tool and isn't in your list, nnn is very helpful in many cases, especially bulk renames and reorganizations.
they either don't improve upon or add functionality that's not available, or simply add eye candy. Gaining pretty colors is nice, but not worth losing familiarity with ubiquitous tools.
The thing I like about a lot of these is that I don't lose familiarity with existing tools. When I end up on a cluster that doesn't have them, I'm a bit annoyed, but I can still operate just fine.
The principle exception to this is actually fd - I now find find (har!) almost unusable without having a man page open in a separate terminal. But that's because fd is so much more ergonomic and powerful, I would never give it up unless forced.
I unfortunately do not have your crystaline perfect recall. I used vi/m for nearly 20 years before drifting onto kakoune and now helix; I've been using them for about a year, and it's getting harder and harder to not make reflexive mistakes when I'm trying to use vim. sed was already odd with regex escaping (parens but not brackets? Why??), and I know the less I use it the more I'll forget. This is crippling when I have to work on a system that doesn't have these new tools installed.
What I mean is that many of them have basically the same functionality with the same arguments. I don't mean I have pristine memory for the differences, but things like alias ls="eza" is basically a drop in replacement with some added features. So when I'm on a server without it, everything is basically the same, just less fancy.
Helix and fd are an example of the other pattern - they are huge improvements over existing tools, to the point that when I'm forced to use the basic ones, I'm actively crippled. But as an argument not to use the better tool day-to-day, this doesn't make sense to me. Why would I force myself to suffer 95% of the time to save myself from suffering 5% of the time?
I mean, for helix/vi it's even clearer. Vanilla vi is basically unusable for me anyway, and I needed a huge number of plugins to be serviceable - on a basic cluster environment, I'm going to be crippled anyway, so...
While itβs not a replacement for an existing tool and isnβt in your list, nnn is very helpful in many cases, especially bulk renames and reorganizations.
Can you give an example on the reorganization benefits with nnn? I am using it myself but I still feel like a noob with it.
So, I did a whole asciinema demonstration to show you, but it was getting tedious. It started to turn into a whole tutorial, and I really didn't want to go there. That's why it's taken so long for me to reply.
But there are three things I do with nnn:
move things. I use the tabs (1-4) to open different directories, space-select multiple items, and 'v' to move selected items to directories
bulk rename. Again, space-select and ctrl-r to bulk rename. Often, I don't even select, I just 'R' to bulk rename the whole directory. This opens my text editor with all of the file/Dir names; edit freely, save, exit, and nnn renames whatever changed.
move/copy to remote locations. With 'c' nnn can mount a remote directory over ssh in a tab, and it works just like a local directory, with copying, moving, and renaming seamlessly between tabs.
I don't "live" in nnn; it's a tool I open when I want to do certain things - it's fast enough to use this way. But you certainly could, since nnn can fork shell processes in selected directories.
The last point is new to me, will check it out, thank you!
Nice, I use almost all these! helix, btm, exa, and delta are wonderful.
Maybe sure to replace exa with eza. Exa has been unmaintained for a while and eza is the maintained replacement.
Ah hadn't realized. Looks like arch AUR was smart about it and yanked exa, and eza had an automatic alias to it.
Please give a try for btop - not Rust based, but pretty good and seem to be superior to btm.
I don't have any particular allegiance to rust, though once it's set up, being able to install through cargo rather than being to figure out whatever package manager or build system is nice, especially on various HPC environments where I don't have sudo.
Btop does look cool though
I like most of those, but helix just sucks. It will never replace vi/vim/nvim. I don't like zellij either, it's not a proper replacement for tmux.
You are of course welcome to your opinion. Use whatever tools bring you joy. But I'm a huge fan of helix, and think zellij is great (though I prefer wezterm's mux server when I can use it).
Can you also give arguments to your opinion?
Some general things:
Both Tmux and Neovim have such broad plugin ecosystems, helix and zellij don't even come close.
For zellij specifically:
I don't like the UI, it's just way too much stuff on the screen, it's distracting. Tmux tries to stay out of the way and only displays something if it's absolutely necessary. You can also configure everything yourself.
Regarding helix:
As a long time Vim/Emacs-evil user I just can't get used to stuff like Kakoune or Helix, it just feels weird.
The thing is, helix has useable defaults, you dont need plugins, thats the whole point for me. Keeping plugins up to date across machines and making sure they work is just tiresome.
In terms of tmux/zellij can't say much, but I never got used to tmux because the controls seem unintuitive. Tested zellji just briefly and it seems it tries to show you the controls instead of hiding them, which is helpful if you are trying to get used to something.
I've not replaced anything just because it's Rust, but I have replaced a fair share of tools, just because their newer Rust equivalents are much better
What for? Even if they have improvements in some areas, the original POSIX standard utilities will continue to be needed for script compatibility. You're not going to swap them out - at best you can add them and then you just have an additional code base to support with additional attack surface to protect.
The uutils project is aiming for full compatibility though, so eventually you will be able to just swap them out.
What for?
Personally, I'm a huge fan in unifying software under one language.
I don't know man, those tools - they seem rusty to me.
The thread needed the joke. Had you not done it, I'd have offered some flavor of it. Bravo!
No. Those tools are tried and well tested. Yes there may still be bugs lurking but simply rewriting in Rust does not guarantee safety. I do hope that this: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html doesn't get used in that repo.
That said, I'll take a look in say five years and see how they are getting on.
Sounds dumb. Like when Java was supposed to be able to do everything, but this is faster. Doesn't make it not dumb.
I wouldn't necessarily call it dumb.
Rust is much more of a drop in replacement for C/C++ than Java ever was, and it carries some serious benefits over C/C++ like proper memory management and a modern library and packaging system.
Rebasing to Rust might genuinely be a good idea for some of these tools.
What's funny is Java solved an issue that is pretty much non-existent in today's environment: compatibility.
It's much less like the Wild West these days. People have a clearer picture of what to support, how to support it, and generic tools to abstract platform-specific code.
I like Java. I think they did good things and had a pragmatic approach to the problems they were trying to solve.
But time goes on, and this young discipline progresses fast. It'll be interesting to see decades from now what languages survive and which ones don't.
I predict as time goes on, we'll get fewer big languages (popular, widespread, useful, etc.) and they will stick around for much longer.
Kind of like human language, if you think about it.
What alternatives? Most of them do different things, often optimized for interactive usecase but lacking in scriptability.
And just because it's in Rust, doesn't mean it's better in code quality or even safer.
I do like fd though.
nushell, since it uses more structured data, is basically moving in this direction.
I am using alacritty for years, just recently discovered helix. So I guess I am a natural convert.
No, but I'd gladly do so if it shows a considerable performance improvement compared to their "standard" counterparts.
ion β€
No, it's a pointless exercise that makes no sense.
Honest question...why?
Some have better ux, some support more platforms out of the box. I don't find it a good idea trying to replace everything though.
I only tend to replace if all of those are met:
So far, only things I've actually replaced are aliasing
lstoexa/eza, and switched toripgrepfor most of my uses ofgrep.coreutils-hybrid (UUTILS for Arch Linux)
UUTILS Site & Index
Looks neat, but again, 99% of those utils I've never ever thought "this shit too slow" or "UX sucks". Replacing for the sake of replacing I'm not too keen on.
They also have the benefit of being in a memory safe language and being cross-platform. Rust does actually have some advantages when it comes to making secure & stable tooling.
This aims to be a drop-in replacement for GNU coreutils and might actually serve to increase security, stability, & speed across the system as a ton of stuff rely on coreutils.
Now it's still not complete, so you can't just replace everything but I've actually noticed an improvement in my system with hybrid.
I know, but coreutils also literally never broke on me as they are. To me, the whole point of coreutils is that they're just... there. I'll leave the decision to change bundled tooling to distro maintainers.
I'll also be perfectly honest: from a developer standpoint, end-users caring about the language a tool was developed with is, in the end, a pretty weird concept to me. Memory safety and cross platform compilation is DX stuff. Nothing tells you as a user that the thing you're using isn't sprinkling
unsafeeverywhere, in the end... The application itself doing what it advertises is what I'd expect most users to care about. Especially for stuff as old and relatively stable as most coreutils.Ah, except Electron. Fuck most Electron apps.
If you go to the uutils repo you can see that it's making proper use of fuzzing, test, etc. and only makes use of unsafe in necessary areas. Uutils is also more consistent with modern standards thanks to
clap& uniform design, has out of the box selinux support, etc.The
unsafekeyword isn't inherently "unsafe", nore does it disable any checks contrary to what some believe.Also many distros are already packaging uutils do to it "growing into remarkably robust shape", it's just not ready to completely replace coreutils quite yet and so it's not up for consideration by distros to ditch coreutils until it's at least at parity. (That's why I make use of hybrid and not outright replacing everything).
The point is not the language, it's how the project is making use of the language and uutils is doing a lot right.
My point was intended to be more generic than just
uutilsthough. Agreed that this specific project looks interesting.And yes, I know the
unsafekeyword is not inherently unsafe to use, but it's also, in practice, one of the few potential footguns of the language, and is easy to abuse and get wrong. It'll raise a few eyebrows in PRs and you'll be expected to have both good reasons and a good test coverage at the very minimum lol. It's a good red flag, if you do end up with runtime memory issues, that it's probably happening in that block, but past this, you're still basically foregoing some safety for convenience. And people fail. Often.Utilities built in Rust have a higher potential for better security, all else being equal.
Uhhhhh, they do?
I don't really thing the security 'guarantees' of rust matter that much.
I think it's a better language to work in than C or C++, though. That's not a reason to change utilities now, but a larger Rust ecosystem is always better in my humble opinion.
Yes thatβs the major selling point in the Rust language in my opinion. Memory safety. Most of the security issues you hear about are because of mismanaged memory, specifically buffer overflows. My understanding is that Rust reduces risk of those by catching them at compile time.
Because Rust is better, hurr-durr.
Forgor the /s
Turns out Lemmy isn't better at understanding sarcasm than Reddit lol.
If the current tools work fine, have decades of historic support and battle testing, and the alternatives offer little to no net benefit, uhh, why?
But rust
Aye, I can't argue with that
Is Rust Web Scale?
Battle hardened > new
Unless the new has a killer feature set worth the trade off in potential bugs
I think that's fair.
Eventually, the Rust-alternatives will be battle-hardened too and we can simply choose what suits us best.
It's a good time for software, honestly.
Agreed that competition only helps us users
Are you still using bash?
Like many others, I don't replace old tools with new ones, simply because it is written in Rust. For example, fzf is a very novel and useful tool that's written in Go. (FYI: Fzf has a Rust alternative called skim). I'm going to restrict the rest of the post to the context of this thread - Rust CLI/TUI programs that I like. But by no means are they the only new ones I like, or always a replacement for the old ones.
fd and ripgrep (rg) have 2 things in common that give them edge over their older counterparts. First is that both are extremely fast compared to their predecessors. Second is that both support a modern (perl-compatible) version of regex syntax that many programming languages support.
Zellij is a terminal multiplexer like Tmux. However, Zellij IMO has one huge advantage over Tmux and screen - you don't need to take a tutorial or read a user guide just to get started. Everything is discoverable and intuitive. Zellij has the potential to replace TMux as the dominant terminal multiplexer in the near future.
You may find zoxide, atuin and starship as good extensions to your terminal experience, depending on your tastes. Zoxide is a smart directory changer (alt for cd) with good integration all around - with a lot of shells, alternatives (data import), editors (emacs, nvim, etc), file browsers (ranger, nnn, etc) and even mail client (aerc). Atuin replaces the history part of GNU Readline. But lately, it has started gaining features not found in readline, like encrypted history and cross-device history sync. Starship may be a bit fancy for shell prompts - but I find its configuration format to be simpler than the old method. It also supports several shells giving you a uniform experience across shells.
GPG-TUI is a TUI frontend to GnuPG. It's useful simply because the GnuPG UI is terrible. Meanwhile, Sequoia PGP is a tool that aims to replace GnuPG altogether. It has some lofty ambitions and has forced the OpenPGP ecosystem to advance a bit. Some of their innovations aim to solve the drawbacks of old OpenPGP - like lack of PKI (instead of just WoT) and Perfect forward secrecy in certain modes. Its defaults are also more sane and modern compared to GnuPG.
Git-UI (Rust) and LazyGit (Go) are TUI frontends for Git - they have no alternatives. I can recommend either of them if you are a heavy user of git - especially interactive staging and interactive rebasing. Meanwhile, git-interactive-rebase-tool is a tool specifically designed to manage interactive rebases.
If you are into coding, you may find Tokei useful. It is tool for counting Lines of code (LoC) in your projects, segregated by language. Hyperfine, from the developer of fd, is used to benchmark applications over several runs, with a lot of configuration options. Bat is a terminal pager, again from the developer of fd. It supports syntax highlighting. I often find uses for that. I'm not aware of another tool with the exact same functionality.
Finally, nushell is showing a lot of promise as a shell with more modern features. It extends the structured data paradigm from powershell.
Forgot to mention stacked-git (stg). This is a tool to deal with patch stacks - much like the age old quilt tool often used by kernel hackers. Unlike quilt, stg uses git to manage a stack of patches. This tool was originally written in Python. It was recently rewritten in Rust by the same team.
Having used stg, it's like having multiple staging indexes in git. This allows you to craft a good commit history like the one you get from using interactive rebasing. Unlike interactive rebasing, you don't have to wait till finishing the feature, in order to achieve that result. If you are a git user and haven't given stg a try yet, I strongly recommend you do. It's a nice tool to have in your development tool chest.
Note that
skimperforms worse thanfzf. There's a new matcher in Rust callednucleowhich is faster, but it currently doesn't have a cli and can only be used inside Helix editor (hx)nuis probably the best shell for ad-hoc data processing, handling all my daily needs in one expression.fdandrghave another thing in common, that they're both 50% shorter than their traditional alternatives /sI am really struggling with this, I heard about nu shell some time ago, but the fact that you had to learn some form of new language made me reluctant to actually try it. As a fisher user I want to have sane usable defaults, without having to learn just another programming language for a "tool".
What am I missing?
It kinda fills a niche.
I use fish for simple command pipelines as well. But traditional shells are not as good when I need to do anything "structured", because they treats almost any value as a string and don't have anonymous functions. The first problem means that you have to parse a string again and again to do anything useful, the second means that when both pipe and
xargsfails you are doomed.Nu solves both of the big problems that matters when you want to do rather complex but ad-hoc processing of data. And with a rather principled design, nu is very easy to learn (fish is already way better than something POSIX like bash though).
Personally another important reason is that I have a Windows machine at work and nushell is much easier than pwsh.
Btw fish is also going to be a "tool in rust" soon :)
fdis pretty cool. It offers a good simplification overfind's syntax.find -name "*file*"vsfd file.rgI don't use often except for colorized output. A lot of Nvim plugins also prefer to use ripgrep over grep.Thanks for your comprehensive comment!
Just to add - gitui doesn't (yet) have the commit signing, so for commiting stuff you still have to use command line, but other features are pretty useful.
Yes. The only things I use regularly that aren't aliased to or replaced by a rust-built tool are
mkdir,ln, andrsync.Probably some others I'm forgetting
I have a strong bias for staying with tools that are installed by default. After this many years working with new systems of my own, containers, and systems where I'm not root, the added value of an alternativehas to be quite high for me to switch a core utility.
Thay said, I've found fd, ripgrep, and helix to meet that criteria. The others, not so much; they either don't improve upon or add functionality that's not available, or simply add eye candy. Gaining pretty colors is nice, but not worth losing familiarity with ubiquitous tools.
git-delta is an exception where the syntax highlighting can make a functional difference in code diffs. Not so much that I think about installing it, or using it outside of indirect VCS configuration, but it is a good example of using style for more than just eye candy. I prefer difftastic, but they do much the same.
While it's not a replacement for an existing tool and isn't in your list, nnn is very helpful in many cases, especially bulk renames and reorganizations.
The thing I like about a lot of these is that I don't lose familiarity with existing tools. When I end up on a cluster that doesn't have them, I'm a bit annoyed, but I can still operate just fine.
The principle exception to this is actually
fd- I now findfind(har!) almost unusable without having a man page open in a separate terminal. But that's becausefdis so much more ergonomic and powerful, I would never give it up unless forced.I unfortunately do not have your crystaline perfect recall. I used vi/m for nearly 20 years before drifting onto kakoune and now helix; I've been using them for about a year, and it's getting harder and harder to not make reflexive mistakes when I'm trying to use vim. sed was already odd with regex escaping (parens but not brackets? Why??), and I know the less I use it the more I'll forget. This is crippling when I have to work on a system that doesn't have these new tools installed.
What I mean is that many of them have basically the same functionality with the same arguments. I don't mean I have pristine memory for the differences, but things like
alias ls="eza"is basically a drop in replacement with some added features. So when I'm on a server without it, everything is basically the same, just less fancy.Helix and fd are an example of the other pattern - they are huge improvements over existing tools, to the point that when I'm forced to use the basic ones, I'm actively crippled. But as an argument not to use the better tool day-to-day, this doesn't make sense to me. Why would I force myself to suffer 95% of the time to save myself from suffering 5% of the time?
I mean, for helix/vi it's even clearer. Vanilla vi is basically unusable for me anyway, and I needed a huge number of plugins to be serviceable - on a basic cluster environment, I'm going to be crippled anyway, so...
Can you give an example on the reorganization benefits with nnn? I am using it myself but I still feel like a noob with it.
So, I did a whole asciinema demonstration to show you, but it was getting tedious. It started to turn into a whole tutorial, and I really didn't want to go there. That's why it's taken so long for me to reply.
But there are three things I do with nnn:
I don't "live" in nnn; it's a tool I open when I want to do certain things - it's fast enough to use this way. But you certainly could, since nnn can fork shell processes in selected directories.
The last point is new to me, will check it out, thank you!
Nice, I use almost all these! helix, btm, exa, and delta are wonderful.
Maybe sure to replace exa with eza. Exa has been unmaintained for a while and eza is the maintained replacement.
Ah hadn't realized. Looks like arch AUR was smart about it and yanked exa, and eza had an automatic alias to it.
Please give a try for btop - not Rust based, but pretty good and seem to be superior to btm.
I don't have any particular allegiance to rust, though once it's set up, being able to install through
cargorather than being to figure out whatever package manager or build system is nice, especially on various HPC environments where I don't have sudo.Btop does look cool though
I like most of those, but helix just sucks. It will never replace vi/vim/nvim. I don't like zellij either, it's not a proper replacement for tmux.
You are of course welcome to your opinion. Use whatever tools bring you joy. But I'm a huge fan of helix, and think zellij is great (though I prefer wezterm's mux server when I can use it).
Can you also give arguments to your opinion?
Some general things: Both Tmux and Neovim have such broad plugin ecosystems, helix and zellij don't even come close.
For zellij specifically: I don't like the UI, it's just way too much stuff on the screen, it's distracting. Tmux tries to stay out of the way and only displays something if it's absolutely necessary. You can also configure everything yourself.
Regarding helix: As a long time Vim/Emacs-evil user I just can't get used to stuff like Kakoune or Helix, it just feels weird.
The thing is, helix has useable defaults, you dont need plugins, thats the whole point for me. Keeping plugins up to date across machines and making sure they work is just tiresome. In terms of tmux/zellij can't say much, but I never got used to tmux because the controls seem unintuitive. Tested zellji just briefly and it seems it tries to show you the controls instead of hiding them, which is helpful if you are trying to get used to something.
I've not replaced anything just because it's Rust, but I have replaced a fair share of tools, just because their newer Rust equivalents are much better
What for? Even if they have improvements in some areas, the original POSIX standard utilities will continue to be needed for script compatibility. You're not going to swap them out - at best you can add them and then you just have an additional code base to support with additional attack surface to protect.
The uutils project is aiming for full compatibility though, so eventually you will be able to just swap them out.
Personally, I'm a huge fan in unifying software under one language.
I don't know man, those tools - they seem rusty to me.
The thread needed the joke. Had you not done it, I'd have offered some flavor of it. Bravo!
No. Those tools are tried and well tested. Yes there may still be bugs lurking but simply rewriting in Rust does not guarantee safety. I do hope that this: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html doesn't get used in that repo.
That said, I'll take a look in say five years and see how they are getting on.
Iβm really looking forward to using something like rust coreutils, but only once the testing passes the gnu test suite (https://github.com/uutils/coreutils-tracking)
Sounds dumb. Like when Java was supposed to be able to do everything, but this is faster. Doesn't make it not dumb.
I wouldn't necessarily call it dumb.
Rust is much more of a drop in replacement for C/C++ than Java ever was, and it carries some serious benefits over C/C++ like proper memory management and a modern library and packaging system.
Rebasing to Rust might genuinely be a good idea for some of these tools.
What's funny is Java solved an issue that is pretty much non-existent in today's environment: compatibility.
It's much less like the Wild West these days. People have a clearer picture of what to support, how to support it, and generic tools to abstract platform-specific code.
I like Java. I think they did good things and had a pragmatic approach to the problems they were trying to solve.
But time goes on, and this young discipline progresses fast. It'll be interesting to see decades from now what languages survive and which ones don't.
I predict as time goes on, we'll get fewer big languages (popular, widespread, useful, etc.) and they will stick around for much longer.
Kind of like human language, if you think about it.
What alternatives? Most of them do different things, often optimized for interactive usecase but lacking in scriptability.
And just because it's in Rust, doesn't mean it's better in code quality or even safer.
I do like fd though.
nushell, since it uses more structured data, is basically moving in this direction.
I am using alacritty for years, just recently discovered helix. So I guess I am a natural convert.
No, but I'd gladly do so if it shows a considerable performance improvement compared to their "standard" counterparts.
ion β€
No, it's a pointless exercise that makes no sense.
Here is an alternative Piped link(s):
this video
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I'm open-source; check me out at GitHub.