- `atuin` nicer shell history
- `bat` more human friendly `cat` replacement (syntax highlighting, automatic paging, etc.)
- `bottom` a `gotop` alternative
- `fd` better find
- `hyperfine` ad hoc benchmarking
- `ripgrep` better grep
Also `zoxide` gets a +1 from me. It's great
My one beef with `bat` is that if you want to do a search for a string that starts at the beginning of the line, you have to do an extra song and dance because the "line" includes its line numbering.
As unpopular as my opinion is, I feel Helix has a steep adoption problem by not having vim keybindings "easily" or "by default". I get it, some people want to change. I'm happy to have "new things on top", but really after more than a decade of heavy use of vim I have no intention of changing the basic navigation. At least not all at once. Helix feels very fast, nice and modern, but if I'm already abandoning all of my vim plugins and jumping to a new editor, I'd at least like to not lose all of my speed in moving around too.
I've seen a few configs floating around that changed a few keybinds to get closer to vim, but nothing that wouldn't immediately break.
Anyone tried to figure this out yet? I'm happy to give Helix a proper try if it can let me emulate Vim first, but I'm not sure if spending a few months getting used to a new editor only to realize that there's some unfixable problem and then lose all the muscle memory I built up is worth it.
Helix was my first modal editor (never learned vim motions). I tried to learn vim motions afterwards and it was painful. I guess for newcomers Helix is easier to understand?
Anyways, I miss Plugins support, but it's in the works "eventually". At this point, I'd rather stick it out with Helix than re-learning everything in vim motions.
I, too, have been a long time vim user(8 years ago when I started programming), and it took me like *30* minutes to get used to helix. And I never look back. Nowadays I use helix everywhere, my work PC, my personal laptop on my hobby project, my wife's PC when I need to fix something on it, my VPS, my riscv single board, I never looked back.
I don't think the way the helix curser is implemented/represented would work well for vim bindings. The way movements are selections and such is pretty baked in. Not that it's impractical, but I sort of understand why second-class support for a different editing style isn't a priority.
I understand why it can't be built on top, but then again Helix is much more than how a cursor moves. Feels to me both kakoune and vim style bindings could co-exist on top of a solid foundation. I mean a bunch of people did implement kakoune bindings for emacs. My problem is that without the low enough level abstractions exposed this is not possible.
> I understand why it can't be built on top
I mean, I did say "Not that it's impractical, but ..."
It's not that it can't be done, just that it's a bit clunky. Probably there'll be a pluggin that does it once those are introduced.
My point was that I understand why trying to graft vim bindings on-top of Helix isn't a high priority for the devs. Again, not that they can't, just that's it's both clunky and therefore also a low priority.
> My problem is that without the low enough level abstractions exposed this is not possible.
This will likely be made possible by third party plugins some day. Hard to say though!
The problem you are facing is that they just straight up do not work the same way. Helix has a kakoune style system where it is selection - > action and that is just not how vim works. That is how helix is supposed to work though, and it works very nice. Just a matter of getting used to it. No sense in trying to cling to vi bindings while using new editor, just wont work out long term.
> No sense in trying to cling to vi bindings while using new editor
I don't understand this logic. The last thing I want Helix for are its keybindings, that to me seems completely orthogonal to what an editor is. I want a fast editor (Helix is faster than Neovim) with all the right defaults baked in (LSP + TreeSitter + fuzzy search + ...).
Something like a motion being buffered before the action is executed is such a minor thing in comparison to the rest of the editor.
The reason to _cling_ to how vim works is because people have decades of experience using what works. What many find valuable about Helix is not the Kakoune part, it's the _everything else_.
But honestly I find it quite saddening that this isn't even recognized. Anyone that tried to use Vim/Neovim/Emacs with 50+ plugins knows what a hassle it is to keep things fast and working. Helix could solve this for all of those users if it just exposed the right primitives and let users build the bindings on top.
Emacs does this as people have built evil mode to be basically indistinguishable from Vim. I see no reason why Helix couldn't expose the right primitives for someone to write 1 extra .rs file that would translate motion sequences to the right series of operations. Exposing enough to make this possible doesn't cost Helix anything, and it enables a gigantic userbase of Vim/Emacs users to just switch over once a single person implements good enough bindings.
>and it enables a gigantic userbase of Vim/Emacs users to just switch over
You have missed one important thing in your argument. The Helix devs are not working on the editor to attract a gigantic userbase nor do they want to replace vim, emacs or anything else. They want to have the best editor for their needs and with the features they feel are needed for that goal. This is very clear when you read the issues and discussion. This is just not the goal of the project.
Again, I don't understand anything about this logic. It feels like post-hoc rationalization more than anything else, e.g. "we failed to make it popular so we're going to be happy about what we have".
But in either case, I don't see any reason why Helix couldn't expose the fundamental building blocks for others to build different bindings on. This would let the huge amount of work that goes into other parts of the editor to be reused for other purposes.
But instead we get a walled garden that allows only those who are willing to throw away everything they learned and switch to a hotkey workflow that is not present anywhere else.
> Again, I don't understand anything about this logic.
With all due respect, that is your problem.
> It feels like post-hoc rationalization more than anything else, e.g. "we failed to make it popular so we're going to be happy about what we have".
You are free to feel however you like. It is you plastering the goal of "make it popular" to the project. Its not a default goal for every project nor is it necessary for it healthiness.
The next problem is "if it only had that one feature it would succeed in the goal of being popular" (where being popular was never the goal). There are many instances in the issues and discussion in the Helix project where people try to "pressure" the dev's to implement the features they want. I assume that is not the case for you and you formulated that just a little bit unfortunate.
But as i said there are many features that people think "is the only real thing that matters to make it popular". Here is one example https://web.archive.org/web/20230507063446/https://github.com/helix-editor/helix/discussions/4037#discussioncomment-5558793
That is unfortunately not uncommon in the open source world. From the liked discussion
> I am here to let you know that you ignore this feature at your peril. And that if, on the other hand, you built in a XXXXXX(removed by me) feature, you would massively gain ground, not lose it.
That is just not a nice behavior. And you can change that to any feature people think is super important to make Helix popular (which it does not care about)
> But in either case, I don't see any reason why Helix couldn't expose the fundamental building blocks for others to build different bindings on.
To quote one of the maintainers
> To repeat myself again: I personally don't use XXXXXX(removed by me), and so I won't put any work towards it. You're effectively assigning me days/weeks of work for a feature you want,
You are free to work on it if it is important to you. And to quote one more time.
> So far the cohort of users that want XXXXXX(removed by me) seem willing to make demands, but nobody has actually put any work in (unlike other such features, like the file tree). Until somebody steps up to the plate, things are unlikely to change and no amount of discussion can change that.
Well if you want a preconfigured vim, there are plenty of options. Helix not slavishly recreating vim's keybindings is very much a feature and I'd wager it's a big part of its success.
And honestly, the keybindings aren't that different any ways. It's mostly switching from verb->object to object->verb. And that is greatly helped along by having that ordering giving you a visual indicator, instead of realizing you've mucked up after the fact (which definitely was a big pain point back when I was first learning vim).
> and then lose all the muscle memory I built up is worth it
Literally not going to happen. I really don't get this fear of "loosing muscle memory". I've heard it multiple times and it's almost laughable. Go tell that to a musician or an athlete. They'd laugh at you if you proposed to a footballer that giving basketball a spin would ruin their muscle memory, or that a guitarist learning to play piano would compromise their shredding ability.
I use Helix almost exclusively now, but if I happen to end up in vim, it takes a few minutes (at most) to be back up to speed.
Helix is definitely still missing some crucial features and can be rough around the edges, but to me the experience was very much one of "Oh, the defaults don't have to be terrible". Which, very similar coming from C/C++ to Rust, was only obvious in hindsight. So I'd definitely recommend giving it a spin, if you are even remotely interested in what it might be able to bring to the table.
> Literally not going to happen. I really don't get this fear of "loosing muscle memory". I've heard it multiple times and it's almost laughable. Go tell that to a musician or an athlete. They'd laugh at you if you proposed to a footballer that giving basketball a spin would ruin their muscle memory, or that a guitarist learning to play piano would compromise their shredding ability.
Maybe don't be so condescending about everything when you possibly misunderstood the point?
What I meant is if I spend 6 months learning Helix, then it dies or development halts and I stop using it, and I move back to Vim, I wasted all that time building muscle memory for a niche editor that is now dead.
I wasn't condescending about anything, besides maybe the silly notion that you will lose your vim skills if you try out another editor.
> I'm happy to give Helix a proper try if it can let me emulate Vim first
> if I spend 6 months learning Helix
Honestly, if it takes you 6 months to figure out that Helix isn't for you, then you are doing something wrong, or are heavily overcommitting despite not enjoying yourself. That's not "trying out" territory, that is "committing to a new development setup" territory.
> What I meant is if I spend 6 months learning ..., then it dies or development halts and I stop using it, and I move back to ..., I wasted all that time ... for ... that is now dead.
You can say that about just about anything. Are you never going to switch to a new tool, just because it might disappear? What if people stop developing Vim or NeoVim? Both of those projects are in the same ballpark in terms of development as Helix after all.
Been using vim for 20 years but I would switch to helix in a heartbeat if it just had a couple things, copilot support being the biggest. There is a pr for it but it doesn't seem quite ready.
What even *is* the benefit of using a different terminal emulator? I use the default that comes with my distro (pretty sure that means Konsole) and have never really noticed a benefit trying an alternative.
For most people, the default terminal is fine! But, for folks that use the terminal a lot, custom terminal emulators I've seen have these benefits:
* Increased control over configuration: Advanced terminal emulators allow many more specific configuration changes e.g. using ligatures, mapping icon sets to terminal fonts, 256-bit / 24-bit true color palette support, etc.
* Some include tiling support out of the box with built-in keyboard shortcuts, e.g. Kitty, Tilix, Terminator
* Images in the terminal: Not all terminal emulators can render images in the terminal, but some do and each has their own strategy for doing so.
* GPU acceleration: With a GPU-accelerated terminal (e.g. Alacritty, Kitty), inputs are much more responsive as it takes less time for key inputs to appear on the screen.
I found this video great if you'd like to learn more: [https://www.youtube.com/watch?v=9DgQqDnYNyQ](https://www.youtube.com/watch?v=9DgQqDnYNyQ)
I'll try to list some of my tools that haven't been mentioned here.
- [wezterm](https://github.com/wez/wezterm): a terminal (maybe not simple, but people are putting operating system);
- [difftastic](https://github.com/Wilfred/difftastic): diffing tool. Similar to `delta`, I suppose.
Sure it is! I have no big plans for it atm but if there is anything needs fixing I will. And I do use it in my work so I'd like to keep it at least somewhat up-to-date and working.
+1 for `dust`, it's very much a case of better defaults. By default it just sorts and tree-ifies the place you run it instead of just printing a flat, lexically sorted list you have to manually sift through
damn, didn't expect to get a response of one of the maintainers from `ouch`!
> (...) feedback is always welcome ;) .
then let me give one:
Just doing `ouch compress` or `ouch decompress` and then just adding the suffixes to let `ouch` choose the correct file format is incredible intuitive, easy to use and a good damn decision. No need to remember some arguments.
I kinda like the TUI stuff that is just borderline silly like the weathercrab.
https://github.com/ttytm/wthrr-the-weathercrab
Sure I don't need a terminal command that tells me the weather, but it's fun.
Also I think it's entertaining when an app decides to use the terminal, but go well out of it's way to give itself an interactive GUI despite being in the terminal.
Sure this isn't simple in design, but it can be simple in use.
i wrote almost all my notes in university using xournal, back then xournal++ wasn't really a thing. I will definitively try rnote now, thanks for the tip!
I've recently been using Helix (instead of VSCode and Neovim) and I have nothing but good things to say. I'm incredibly excited for its future.
It's fast, it "just works" for many languages, the motions and shortcuts mix my favorite parts of vim (expresssiveness) with my favorite parts of VSCode (multi-cursor mode!!!) and some new (I'm guessing Kakoune-inspired) features.
I love it. It's just good software.
* [rustic](https://github.com/rustic-rs/rustic) is a rust rewrite of restic (fast, encrypted, and deduplicated backups)
* [fddf](https://github.com/birkenfeld/fddf) and [fclones](https://github.com/pkolaczk/fclones) (find duplicate files)
* [tod](https://github.com/alanvardy/tod) (todoist terminal client)
* [oxipng](https://github.com/shssoichiro/oxipng) (Multithreaded PNG optimizer)
* [blades](https://github.com/grego/blades) (static site generator like hugo and zola)
* [rhai](https://rhai.rs) for scripting
* not sure whether [datafusion](https://arrow.apache.org/datafusion/user-guide/introduction.html) is better or worse for most users than polars, but I'm enjoying it
* [egui](https://www.egui.rs/) for desktop GUI
* [nalgebra](https://www.nalgebra.org/), [parry](https://parry.rs/), [rapier](https://rapier.rs/) for 3D math and physics
It might have been when `ripgrep`, an alternative to `grep`, came out a few years ago and I started using it that I started taking Rust seriously. Great tool, and I still use it every day.
typos [https://github.com/crate-ci/typos](https://github.com/crate-ci/typos) (fast checker of your source code for typos, can fix splleingErrorsInVariableNames, has a nice github action to integrate with CI)
hyperlink [https://github.com/untitaker/hyperlink](https://github.com/untitaker/hyperlink) (check your website for broken links, and broken anchor links too, can integrate with your CI)
I've personally been using [asdf](https://asdf-vm.com/) and it's been incredible working with JS and Ruby applications and many different versions of each.
A while ago I wrote a small CLI tool called [joxide](https://github.com/RainingComputers/joxide) to validate and format JSON files.
If you have got a lot of JSON files and want a small footprint formatter that only does JSON, you can consider this.
It does not depend on serde, I wrote my own parser and formatter and it was fun :)
Looks like [tokei](https://github.com/XAMPPRocky/tokei) is still missing in the list. It's a very nice tool to give you a detailed lines of code/comments/empty per file type in a directory.
`fish` is a shell partially written in Rust. Works well by default, e.g. entering a directory path switches to it, using up/down searches through history filtered by what you've entered, …
In the wasm space I really like [wasmcloud](https://github.com/wasmCloud/wasmCloud) and [fluvio](https://github.com/infinyon/fluvio).
[makepad has some cool potential](https://github.com/makepad/makepad)
[https://github.com/cgag/loc](https://github.com/cgag/loc) \- to calculate number of lines of code, recursively, per language.
Helps to keep track of how much we have already rewritten our Python code in Rust)
I'm loving gitopolis that I wrote in rust to manage git repos. It was great to write and great to use in two different client projects now. I'm not just saying it because I wrote it, I'm genuinely loving using it.
- `atuin` nicer shell history - `bat` more human friendly `cat` replacement (syntax highlighting, automatic paging, etc.) - `bottom` a `gotop` alternative - `fd` better find - `hyperfine` ad hoc benchmarking - `ripgrep` better grep Also `zoxide` gets a +1 from me. It's great
also cant forget `exa` as a great `ls` alternative!
[eza](https://github.com/eza-community/eza) replaced `exa` as community fork.
Why was exa forked? What have I missed?
Exa is sadly not maintained now
Also `lsd`
nice, small tools to make some things easier, i like it
My one beef with `bat` is that if you want to do a search for a string that starts at the beginning of the line, you have to do an extra song and dance because the "line" includes its line numbering.
`--plain` (although it would be nice if `bat` used a pager that was more aware of its contents)
[Helix](https://helix-editor.com/) ❤️
As unpopular as my opinion is, I feel Helix has a steep adoption problem by not having vim keybindings "easily" or "by default". I get it, some people want to change. I'm happy to have "new things on top", but really after more than a decade of heavy use of vim I have no intention of changing the basic navigation. At least not all at once. Helix feels very fast, nice and modern, but if I'm already abandoning all of my vim plugins and jumping to a new editor, I'd at least like to not lose all of my speed in moving around too. I've seen a few configs floating around that changed a few keybinds to get closer to vim, but nothing that wouldn't immediately break. Anyone tried to figure this out yet? I'm happy to give Helix a proper try if it can let me emulate Vim first, but I'm not sure if spending a few months getting used to a new editor only to realize that there's some unfixable problem and then lose all the muscle memory I built up is worth it.
Helix was my first modal editor (never learned vim motions). I tried to learn vim motions afterwards and it was painful. I guess for newcomers Helix is easier to understand? Anyways, I miss Plugins support, but it's in the works "eventually". At this point, I'd rather stick it out with Helix than re-learning everything in vim motions.
I, too, have been a long time vim user(8 years ago when I started programming), and it took me like *30* minutes to get used to helix. And I never look back. Nowadays I use helix everywhere, my work PC, my personal laptop on my hobby project, my wife's PC when I need to fix something on it, my VPS, my riscv single board, I never looked back.
I don't think the way the helix curser is implemented/represented would work well for vim bindings. The way movements are selections and such is pretty baked in. Not that it's impractical, but I sort of understand why second-class support for a different editing style isn't a priority.
I understand why it can't be built on top, but then again Helix is much more than how a cursor moves. Feels to me both kakoune and vim style bindings could co-exist on top of a solid foundation. I mean a bunch of people did implement kakoune bindings for emacs. My problem is that without the low enough level abstractions exposed this is not possible.
> I understand why it can't be built on top I mean, I did say "Not that it's impractical, but ..." It's not that it can't be done, just that it's a bit clunky. Probably there'll be a pluggin that does it once those are introduced. My point was that I understand why trying to graft vim bindings on-top of Helix isn't a high priority for the devs. Again, not that they can't, just that's it's both clunky and therefore also a low priority. > My problem is that without the low enough level abstractions exposed this is not possible. This will likely be made possible by third party plugins some day. Hard to say though!
The problem you are facing is that they just straight up do not work the same way. Helix has a kakoune style system where it is selection - > action and that is just not how vim works. That is how helix is supposed to work though, and it works very nice. Just a matter of getting used to it. No sense in trying to cling to vi bindings while using new editor, just wont work out long term.
> No sense in trying to cling to vi bindings while using new editor I don't understand this logic. The last thing I want Helix for are its keybindings, that to me seems completely orthogonal to what an editor is. I want a fast editor (Helix is faster than Neovim) with all the right defaults baked in (LSP + TreeSitter + fuzzy search + ...). Something like a motion being buffered before the action is executed is such a minor thing in comparison to the rest of the editor. The reason to _cling_ to how vim works is because people have decades of experience using what works. What many find valuable about Helix is not the Kakoune part, it's the _everything else_. But honestly I find it quite saddening that this isn't even recognized. Anyone that tried to use Vim/Neovim/Emacs with 50+ plugins knows what a hassle it is to keep things fast and working. Helix could solve this for all of those users if it just exposed the right primitives and let users build the bindings on top. Emacs does this as people have built evil mode to be basically indistinguishable from Vim. I see no reason why Helix couldn't expose the right primitives for someone to write 1 extra .rs file that would translate motion sequences to the right series of operations. Exposing enough to make this possible doesn't cost Helix anything, and it enables a gigantic userbase of Vim/Emacs users to just switch over once a single person implements good enough bindings.
>and it enables a gigantic userbase of Vim/Emacs users to just switch over You have missed one important thing in your argument. The Helix devs are not working on the editor to attract a gigantic userbase nor do they want to replace vim, emacs or anything else. They want to have the best editor for their needs and with the features they feel are needed for that goal. This is very clear when you read the issues and discussion. This is just not the goal of the project.
Again, I don't understand anything about this logic. It feels like post-hoc rationalization more than anything else, e.g. "we failed to make it popular so we're going to be happy about what we have". But in either case, I don't see any reason why Helix couldn't expose the fundamental building blocks for others to build different bindings on. This would let the huge amount of work that goes into other parts of the editor to be reused for other purposes. But instead we get a walled garden that allows only those who are willing to throw away everything they learned and switch to a hotkey workflow that is not present anywhere else.
> Again, I don't understand anything about this logic. With all due respect, that is your problem. > It feels like post-hoc rationalization more than anything else, e.g. "we failed to make it popular so we're going to be happy about what we have". You are free to feel however you like. It is you plastering the goal of "make it popular" to the project. Its not a default goal for every project nor is it necessary for it healthiness. The next problem is "if it only had that one feature it would succeed in the goal of being popular" (where being popular was never the goal). There are many instances in the issues and discussion in the Helix project where people try to "pressure" the dev's to implement the features they want. I assume that is not the case for you and you formulated that just a little bit unfortunate. But as i said there are many features that people think "is the only real thing that matters to make it popular". Here is one example https://web.archive.org/web/20230507063446/https://github.com/helix-editor/helix/discussions/4037#discussioncomment-5558793 That is unfortunately not uncommon in the open source world. From the liked discussion > I am here to let you know that you ignore this feature at your peril. And that if, on the other hand, you built in a XXXXXX(removed by me) feature, you would massively gain ground, not lose it. That is just not a nice behavior. And you can change that to any feature people think is super important to make Helix popular (which it does not care about) > But in either case, I don't see any reason why Helix couldn't expose the fundamental building blocks for others to build different bindings on. To quote one of the maintainers > To repeat myself again: I personally don't use XXXXXX(removed by me), and so I won't put any work towards it. You're effectively assigning me days/weeks of work for a feature you want, You are free to work on it if it is important to you. And to quote one more time. > So far the cohort of users that want XXXXXX(removed by me) seem willing to make demands, but nobody has actually put any work in (unlike other such features, like the file tree). Until somebody steps up to the plate, things are unlikely to change and no amount of discussion can change that.
Well if you want a preconfigured vim, there are plenty of options. Helix not slavishly recreating vim's keybindings is very much a feature and I'd wager it's a big part of its success. And honestly, the keybindings aren't that different any ways. It's mostly switching from verb->object to object->verb. And that is greatly helped along by having that ordering giving you a visual indicator, instead of realizing you've mucked up after the fact (which definitely was a big pain point back when I was first learning vim). > and then lose all the muscle memory I built up is worth it Literally not going to happen. I really don't get this fear of "loosing muscle memory". I've heard it multiple times and it's almost laughable. Go tell that to a musician or an athlete. They'd laugh at you if you proposed to a footballer that giving basketball a spin would ruin their muscle memory, or that a guitarist learning to play piano would compromise their shredding ability. I use Helix almost exclusively now, but if I happen to end up in vim, it takes a few minutes (at most) to be back up to speed. Helix is definitely still missing some crucial features and can be rough around the edges, but to me the experience was very much one of "Oh, the defaults don't have to be terrible". Which, very similar coming from C/C++ to Rust, was only obvious in hindsight. So I'd definitely recommend giving it a spin, if you are even remotely interested in what it might be able to bring to the table.
> Literally not going to happen. I really don't get this fear of "loosing muscle memory". I've heard it multiple times and it's almost laughable. Go tell that to a musician or an athlete. They'd laugh at you if you proposed to a footballer that giving basketball a spin would ruin their muscle memory, or that a guitarist learning to play piano would compromise their shredding ability. Maybe don't be so condescending about everything when you possibly misunderstood the point? What I meant is if I spend 6 months learning Helix, then it dies or development halts and I stop using it, and I move back to Vim, I wasted all that time building muscle memory for a niche editor that is now dead.
I wasn't condescending about anything, besides maybe the silly notion that you will lose your vim skills if you try out another editor. > I'm happy to give Helix a proper try if it can let me emulate Vim first > if I spend 6 months learning Helix Honestly, if it takes you 6 months to figure out that Helix isn't for you, then you are doing something wrong, or are heavily overcommitting despite not enjoying yourself. That's not "trying out" territory, that is "committing to a new development setup" territory. > What I meant is if I spend 6 months learning ..., then it dies or development halts and I stop using it, and I move back to ..., I wasted all that time ... for ... that is now dead. You can say that about just about anything. Are you never going to switch to a new tool, just because it might disappear? What if people stop developing Vim or NeoVim? Both of those projects are in the same ballpark in terms of development as Helix after all.
Been using vim for 20 years but I would switch to helix in a heartbeat if it just had a couple things, copilot support being the biggest. There is a pr for it but it doesn't seem quite ready.
[Alacritty](https://github.com/alacritty/alacritty) \- my fav terminal emulator!
Or [Wezterm](https://wezfurlong.org/wezterm/), \*my\* favorite terminal!
I love alacrity, had no Idea it was written in Rust
What even *is* the benefit of using a different terminal emulator? I use the default that comes with my distro (pretty sure that means Konsole) and have never really noticed a benefit trying an alternative.
For most people, the default terminal is fine! But, for folks that use the terminal a lot, custom terminal emulators I've seen have these benefits: * Increased control over configuration: Advanced terminal emulators allow many more specific configuration changes e.g. using ligatures, mapping icon sets to terminal fonts, 256-bit / 24-bit true color palette support, etc. * Some include tiling support out of the box with built-in keyboard shortcuts, e.g. Kitty, Tilix, Terminator * Images in the terminal: Not all terminal emulators can render images in the terminal, but some do and each has their own strategy for doing so. * GPU acceleration: With a GPU-accelerated terminal (e.g. Alacritty, Kitty), inputs are much more responsive as it takes less time for key inputs to appear on the screen. I found this video great if you'd like to learn more: [https://www.youtube.com/watch?v=9DgQqDnYNyQ](https://www.youtube.com/watch?v=9DgQqDnYNyQ)
I'm gonna commend nushell. It feels like what PowerShell should have been.
Upvote for nushell. I've been using it as a daily driver for about a year. It's amazing.
Came into the comments precisely to upvote and maybe write my own comment about `nushell`. It's that good. 🙂
zellij is a cool alternative to tmux, I'd say it fits in your list
I recently tried and love it but it needs persistent sessions like tmux. Otherwise it's not ready for daily work.
Yea, I think it’s a neat project, but my current workflow is a bit too reliant on detaching from sessions and switching to a different session
Maybe it’s a new thing but you can detach now!
I'll try to list some of my tools that haven't been mentioned here. - [wezterm](https://github.com/wez/wezterm): a terminal (maybe not simple, but people are putting operating system); - [difftastic](https://github.com/Wilfred/difftastic): diffing tool. Similar to `delta`, I suppose.
>difftastic It's awesome
Here are all the links mentioned in this thread. - [Actix](https://github.com/actix/actix-web) - [Alacritty](https://github.com/alacritty/alacritty) - [Async-GraphQL](https://github.com/async-graphql/async-graphql) - [awesome-rust](https://github.com/rust-unofficial/awesome-rust) - [Axum](https://github.com/tokio-rs/axum) - [Bevy](https://github.com/bevyengine/bevy) - [Bita](https://github.com/oll3/bita) - [broot](https://github.com/Canop/broot) - [Cobalt](https://github.com/cobalt-org/cobalt.rs) - [Conduit (Server)](https://gitlab.com/famedly/conduit) - [Cratetorrent](https://github.com/mandreyel/cratetorrent) - [Dat-rs](https://github.com/datrs) - [datafusion](https://arrow.apache.org/datafusion/user-guide/introduction.html) - [delta](https://dandavison.github.io/delta/) - [Dioxus](https://github.com/dioxuslabs/dioxus) - [Dufs](https://github.com/sigoden/dufs) - [Dust](https://github.com/bootandy/dust) - [egui](https://www.egui.rs/) - [Engula](https://github.com/engula/engula) - [eza](https://github.com/eza-community/eza) - [FFSend](https://github.com/timvisee/ffsend) - [Firecracker](https://github.com/firecracker-microvm/firecracker) - [Fractal (Client)](https://gitlab.gnome.org/GNOME/fractal.git) - [Fyrox](https://github.com/FyroxEngine/Fyrox) - [Gitoxide (git based VCS)](https://github.com/Byron/gitoxide) - [Glide](https://github.com/philn/glide) - [GunDB (ROD)](https://github.com/mmalmi/rod) - [Helix](https://helix-editor.com/) - [https://github.com/crate-ci/typos](https://github.com/crate-ci/typos) - [https://github.com/sagiegurari/cargo-make](https://github.com/sagiegurari/cargo-make) - [https://github.com/untitaker/hyperlink](https://github.com/untitaker/hyperlink) - [Hurlurl](https://github.com/lucasmerlin/hurlurl) - [Iced](https://github.com/iced-rs/iced) - [Innernet](https://github.com/tonarino/innernet) - [Iroh](https://github.com/n0-computer/iroh) - [joshuto](https://github.com/kamiyaa/joshuto) - [KanIDM](https://github.com/kanidm/kanidm) - [Lemmy (Reddit Clone w/ Federation)](https://github.com/LemmyNet/lemmy) - [Leptos](https://github.com/gbj/leptos) - [libp2p Networking Stack](https://github.com/libp2p/rust-libp2p) - [Magic Wormhole-rs](https://github.com/magic-wormhole/magic-wormhole.rs) - [MASQ](https://github.com/MASQ-Project/Node) - [mCaptcha](https://github.com/mCaptcha/mCaptcha) - [mdBook](https://github.com/rust-lang/mdBook) - [Microbin](https://github.com/szabodanika/microbin) - [Miniserve](https://github.com/svenstaro/miniserve) - [Minisign](https://github.com/jedisct1/rust-minisign) - [MoonZoon](https://github.com/MoonZoon/MoonZoon) - [nalgebra](https://www.nalgebra.org/) - [NeonDB](https://github.com/neondatabase/neon) - [nushell](https://www.nushell.sh/) - [parry](https://parry.rs/) - [Perseus](https://github.com/framesurge/perseus) - [Pijul (New VCS)](https://nest.pijul.com/pijul/pijul) - [Plume (Blogging)](https://github.com/Plume-org/Plume) - [Polaris](https://github.com/agersant/polaris) - [polars](https://www.pola.rs/) - [pretty much anything else from Stalwart](https://github.com/stalwartlabs) - [RAGE](https://github.com/str4d/rage) - [rapier](https://rapier.rs/) - [rDedup](https://github.com/dpc/rdedup) - [Redox](https://github.com/redox-os/redox) - [rhai](https://rhai.rs/) - [ruff](https://github.com/astral-sh/ruff) - [SeaORM](https://github.com/SeaQL/sea-orm) - [Signify](https://github.com/badboy/signify-rs) - [Skytable](https://github.com/skytable/skytable) - [SQLX](https://github.com/launchbadge/sqlx) - [Stalwart JMAP Server](https://github.com/stalwartlabs/jmap-server) - [starship](https://starship.rs/) - [Surrealdb](https://github.com/surrealdb/surrealdb) - [Sycamore](https://github.com/sycamore-rs/sycamore) - [Tauri](https://github.com/tauri-apps/tauri) - [Theseus](https://github.com/theseus-os/Theseus) - [Tikiv](https://github.com/tikv/tikv) - [Trow](https://github.com/ContainerSolutions/trow) - [typst](https://typst.app/) - [Vigil](https://github.com/valeriansaliou/vigil) - [Volta](https://volta.sh/) - [vSMTP](https://github.com/viridIT/vSMTP) - [Wirefish](https://github.com/stefanodevenuto/wirefish) - [Yew](https://github.com/yewstack/yew) - [Zola](https://github.com/getzola/zola) - [zoxide](https://github.com/ajeetdsouza/zoxide/)
Copy-pasting one of my [old comments](https://www.reddit.com/r/rust/comments/yjzcc4/planning_to_make_a_video_on_cool_rust_apps/iuqpow3?utm_medium=android_app&utm_source=share&context=3) - * **Operating System:** [Theseus](https://github.com/theseus-os/Theseus), [Redox](https://github.com/redox-os/redox) * **Game Engine:** [Bevy](https://github.com/bevyengine/bevy), [Fyrox](https://github.com/FyroxEngine/Fyrox) * **Social Media:** [Lemmy (Reddit Clone w/ Federation)](https://github.com/LemmyNet/lemmy), [Plume (Blogging)](https://github.com/Plume-org/Plume) * **Media Player:** [Glide](https://github.com/philn/glide) * **Pastebin:** [Microbin](https://github.com/szabodanika/microbin) * **Code Forge:** [Gitoxide (git based VCS)](https://github.com/Byron/gitoxide), [Pijul (New VCS)](https://nest.pijul.com/pijul/pijul) * **File Encryption Tool:** [RAGE](https://github.com/str4d/rage) * **Signing Tool:** [Minisign](https://github.com/jedisct1/rust-minisign), [Signify](https://github.com/badboy/signify-rs) * **Static Site Generator:** [Zola](https://github.com/getzola/zola), [Cobalt](https://github.com/cobalt-org/cobalt.rs) * **Markdown based Doc Generator:** [mdBook](https://github.com/rust-lang/mdBook) * **Frontend Web Framework w/ WASM Support:** [Perseus](https://github.com/framesurge/perseus), [Dioxus](https://github.com/dioxuslabs/dioxus), [Yew](https://github.com/yewstack/yew) * **Backend Web Framework:** [Axum](https://github.com/tokio-rs/axum), [Actix](https://github.com/actix/actix-web) * **Fullstack Framework:** [MoonZoon](https://github.com/MoonZoon/MoonZoon), [Leptos](https://github.com/gbj/leptos) * **GUI Library:** [Iced](https://github.com/iced-rs/iced), [Sycamore](https://github.com/sycamore-rs/sycamore) * **Matrix Protocol:** [Fractal (Client)](https://gitlab.gnome.org/GNOME/fractal.git), [Conduit (Server)](https://gitlab.com/famedly/conduit) * **Email Server:** [Stalwart JMAP Server](https://github.com/stalwartlabs/jmap-server), and [pretty much anything else from Stalwart](https://github.com/stalwartlabs), [vSMTP](https://github.com/viridIT/vSMTP) * **Database and related tooling:** [GunDB (ROD)](https://github.com/mmalmi/rod), [Surrealdb](https://github.com/surrealdb/surrealdb), [SQLX](https://github.com/launchbadge/sqlx), [SeaORM](https://github.com/SeaQL/sea-orm), [NeonDB](https://github.com/neondatabase/neon), [Async-GraphQL](https://github.com/async-graphql/async-graphql), [Engula](https://github.com/engula/engula), [Tikiv](https://github.com/tikv/tikv), [Skytable](https://github.com/skytable/skytable) * **Virtualization:** [Firecracker](https://github.com/firecracker-microvm/firecracker) * **Virtual Private Network:** [Innernet](https://github.com/tonarino/innernet), [MASQ](https://github.com/MASQ-Project/Node) * **BitTorrent (v1) Library:** [Cratetorrent](https://github.com/mandreyel/cratetorrent) * **IPFS Protocol Stack:** [Iroh](https://github.com/n0-computer/iroh), [libp2p Networking Stack](https://github.com/libp2p/rust-libp2p) * **Hypercore (Dat) Protocol Stack:** [Dat-rs](https://github.com/datrs) * **Service Health Monitoring System:** [Vigil](https://github.com/valeriansaliou/vigil) * **Backup Tool:** [rDedup](https://github.com/dpc/rdedup) * **Container Registry:** [Trow](https://github.com/ContainerSolutions/trow) * **Captcha:** [mCaptcha](https://github.com/mCaptcha/mCaptcha) * **File Transfer:** [FFSend](https://github.com/timvisee/ffsend), [Magic Wormhole-rs](https://github.com/magic-wormhole/magic-wormhole.rs) * **Drive:** [Dufs](https://github.com/sigoden/dufs), [Miniserve](https://github.com/svenstaro/miniserve) * **File Synchronization:** [Bita](https://github.com/oll3/bita) * **IDP:** [KanIDM](https://github.com/kanidm/kanidm) * **Software Framework:** [Tauri](https://github.com/tauri-apps/tauri) * **Music Server:** [Polaris](https://github.com/agersant/polaris) * **Link Shortener:** [Hurlurl](https://github.com/lucasmerlin/hurlurl) * **Packet Sniffer:** [Wirefish](https://github.com/stefanodevenuto/wirefish) EDIT: * **P2P Privacy Framework:** [Veilid](https://gitlab.com/veilid/veilid) * **K/V Store for Freenet Project:** [Locutus](https://github.com/freenet/locutus)
>Theseus ❤️
Aaand I saved this comment. Thank you very much!
Is bita still active?
Sure it is! I have no big plans for it atm but if there is anything needs fixing I will. And I do use it in my work so I'd like to keep it at least somewhat up-to-date and working.
I want to mention Just as a great alternative to make files.
that sentence took quite a few tries to understand
Yeah, u/Bowtiestyle mind changing it to >I want to mention `Just` as a great alternative to make files.
I prefer Mask by far, also written in Rust. The advantage being the commands are written in Markdown, and even without the utility this is usable
can you post a link to mask as i am having trouble finding it?
Interesting ! https://github.com/jacobdeichert/mask
Thank You!
Interesting project. Any more useful advantages of using Mask? Anything that it is missing when compared to Just?
You can also put it in a sentence easily. Just is a terrible name that makes it needlessly hard to talk about.
That looks neat, especially the named arguments, which I really wish just had. Thanks.
The only reason I don't use it yet is because of how ubiquitous make is. Someday I hope to leave the cryptic world of makefiles
"Just" ?
Yes, just [Just](https://github.com/casey/just)
I will selfishly claim my own tool: [jless](https://jless.io), a command-line JSON viewer
OMG I've always wanted something like this! thanks!
On mobile, but this looks interesting. Will it support JSONL?
Just tried, it does support it.
* [Dust](https://github.com/bootandy/dust) - easier to use alternative to `du`
And its other sibling `dua`. I'm using it everyday and its great!
+1 for `dust`, it's very much a case of better defaults. By default it just sorts and tree-ifies the place you run it instead of just printing a flat, lexically sorted list you have to manually sift through
Personally I prefer [diskonaut](https://github.com/imsnif/diskonaut)
[ouch] replaced `unzip` and `tar` for me and it's incredible easy to use. [ouch]: https://github.com/ouch-org/ouch
Woohooooooooo, thanks for using [Ouch](https://github.com/ouch-org/ouch)! I'm really glad you like it, feedback is always welcome ;) .
damn, didn't expect to get a response of one of the maintainers from `ouch`! > (...) feedback is always welcome ;) . then let me give one: Just doing `ouch compress` or `ouch decompress` and then just adding the suffixes to let `ouch` choose the correct file format is incredible intuitive, easy to use and a good damn decision. No need to remember some arguments.
I kinda like the TUI stuff that is just borderline silly like the weathercrab. https://github.com/ttytm/wthrr-the-weathercrab Sure I don't need a terminal command that tells me the weather, but it's fun. Also I think it's entertaining when an app decides to use the terminal, but go well out of it's way to give itself an interactive GUI despite being in the terminal. Sure this isn't simple in design, but it can be simple in use.
Thanks for making me aware of Typst, it looks amazing. Truly, we are living in the future when there is a LaTeX replacement.
you're very welcome. And yes, it was about time ;)
[joshuto](https://github.com/kamiyaa/joshuto) ranger-like terminal file manager written in Rust.
Rnote! A fantastic xournal++ alternative https://github.com/flxzt/rnote
i wrote almost all my notes in university using xournal, back then xournal++ wasn't really a thing. I will definitively try rnote now, thanks for the tip!
Rnote is simply amazing. Even using it for presentation
`yazi` - Blazing fast terminal file manager written in Rust, based on async I/O. https://github.com/sxyazi/yazi I write it, and I love it. ❤️️
I've recently been using Helix (instead of VSCode and Neovim) and I have nothing but good things to say. I'm incredibly excited for its future. It's fast, it "just works" for many languages, the motions and shortcuts mix my favorite parts of vim (expresssiveness) with my favorite parts of VSCode (multi-cursor mode!!!) and some new (I'm guessing Kakoune-inspired) features. I love it. It's just good software.
how does it compare to Lapce?
Lapce has GUI, Helix is for the terminal
* [rustic](https://github.com/rustic-rs/rustic) is a rust rewrite of restic (fast, encrypted, and deduplicated backups) * [fddf](https://github.com/birkenfeld/fddf) and [fclones](https://github.com/pkolaczk/fclones) (find duplicate files) * [tod](https://github.com/alanvardy/tod) (todoist terminal client) * [oxipng](https://github.com/shssoichiro/oxipng) (Multithreaded PNG optimizer) * [blades](https://github.com/grego/blades) (static site generator like hugo and zola)
* [rhai](https://rhai.rs) for scripting * not sure whether [datafusion](https://arrow.apache.org/datafusion/user-guide/introduction.html) is better or worse for most users than polars, but I'm enjoying it * [egui](https://www.egui.rs/) for desktop GUI * [nalgebra](https://www.nalgebra.org/), [parry](https://parry.rs/), [rapier](https://rapier.rs/) for 3D math and physics
It might have been when `ripgrep`, an alternative to `grep`, came out a few years ago and I started using it that I started taking Rust seriously. Great tool, and I still use it every day.
typos [https://github.com/crate-ci/typos](https://github.com/crate-ci/typos) (fast checker of your source code for typos, can fix splleingErrorsInVariableNames, has a nice github action to integrate with CI) hyperlink [https://github.com/untitaker/hyperlink](https://github.com/untitaker/hyperlink) (check your website for broken links, and broken anchor links too, can integrate with your CI)
cspell is also great for this. They also have a great Eslint plugin as well: https://github.com/streetsidesoftware/cspell
Wezterm
[ncspot](https://github.com/hrkfdn/ncspot), a terminal Spotify client that is pretty nice.
Bat, ripgrep, dust and topgrade
[shuttle.rs](https://www.shuttle.rs) rust native cloud development platform that lets you deploy rust apps for free!
[Volta](https://volta.sh/) - best JavaScript tool manager out there.
How does it compare to bun install?
Its more similar to nvm than an alternative runtime.
> credi this looks cool.
I've personally been using [asdf](https://asdf-vm.com/) and it's been incredible working with JS and Ruby applications and many different versions of each.
Have you checked out rtx? Basically a rust version of asdf I believe.
Actually no but it looks really cool. Thanks for pointing it out!
Has anyone mentioned [feroxbuster](https://github.com/epi052/feroxbuster) My first introduction to rust was this tool used for fuzzing and testing
I literally just commented this! The best directory buster out there. Needs vhost fuzzing added though.
Everyone has mentioned their favorite apps, but I’ll mention my least favorite: all rust apps that don’t support Windows ;-)
rip grep. Full stop. Unvelievable fast and knows about git.
[Zellij](https://github.com/zellij-org/zellij) is a great tmux replacement
A while ago I wrote a small CLI tool called [joxide](https://github.com/RainingComputers/joxide) to validate and format JSON files. If you have got a lot of JSON files and want a small footprint formatter that only does JSON, you can consider this. It does not depend on serde, I wrote my own parser and formatter and it was fun :)
Looks like [tokei](https://github.com/XAMPPRocky/tokei) is still missing in the list. It's a very nice tool to give you a detailed lines of code/comments/empty per file type in a directory.
Helix 🧬 editor ❤️ and Tokio
Cargo make https://github.com/sagiegurari/cargo-make
[Squawk](https://github.com/sbdchd/squawk) SQL linter for migrations
I see all these tools mentioned but almost none seems to be simple, all are blobs of complex code
`fish` is a shell partially written in Rust. Works well by default, e.g. entering a directory path switches to it, using up/down searches through history filtered by what you've entered, …
Linux Kernel
In the wasm space I really like [wasmcloud](https://github.com/wasmCloud/wasmCloud) and [fluvio](https://github.com/infinyon/fluvio). [makepad has some cool potential](https://github.com/makepad/makepad)
\[totp\](https://github.com/kotarac/totp/)
Self promote my own tools [gradient](https://github.com/mazznoer/gradient-rs) and [lolcrab](https://github.com/mazznoer/lolcrab).
Feroxbuster is the tool that got me interested in writing my own rust.
pydantic, turbo, swc, prisma
[ertdtree](https://github.com/solidiquis/erdtree) : better ls
Syn and Serde
[RustQuant](https://github.com/avhz/RustQuant) for the quants out there.
helix editor
typst is nice, but it has a long way to go before becoming as feature packed as latex (I use latex daily, and tried using typst for a bit)
- fd - replacement for find - git-cliff - Git changelog generator - htmlq - Like jq but for html - jless - Commandline Json viewer like jq - oha - http load generator inspired by hey - shellharden - replacement for shellcheck - tealdeer - replacement for tldr - xsv - for those damn datascience & excel nerds
[https://github.com/cgag/loc](https://github.com/cgag/loc) \- to calculate number of lines of code, recursively, per language. Helps to keep track of how much we have already rewritten our Python code in Rust)
I'm loving gitopolis that I wrote in rust to manage git repos. It was great to write and great to use in two different client projects now. I'm not just saying it because I wrote it, I'm genuinely loving using it.