Will definitely prioritize optimization in the next releases. Planning to benchmark against ls on various systems and file counts to get this properly sorted.
Thanks for the great list! Yep, eza and g are fantastic - I actually use eza daily and love how g handles git integration.
What made me excited to experiment with lla was playing with the plugin architecture. While these other tools have great built-in features, I wanted to see if I could make something where the community could easily add their own capabilities without touching the core code. Kind of like how vim and neovim handle plugins.
Got inspired by how people keep building these ls alternatives to scratch their own unique itches. Figured why not make it easier for everyone to scratch their own itch through plugins? Still very much an experiment, but it's been fun seeing what's possible!
Thanks @benrutter! You nailed it - ls is like the "Hello World" of system tools. Simple enough that you won't tear your hair out, but meaty enough to learn a ton.
Started with "ooh, pretty colors!" and before I knew it I was deep in filesystem APIs and terminal wizardry. Way less scary than tackling grep.
Sometimes the best projects are the ones where you can't mess up too badly... well, unless you accidentally delete everything while testing
That's the amazing part I'm talking about the learning experience you get from weeks of working on something like that is better than reading countless documentations
Oh, of course the development is fun and exciting and a learning experience.
But before inviting others to use something, please think of how to make its use more clear. After all, I assume you post this so that people use it, not only admire your coding skills. There is a group of people who have learned to read and rely on man pages.
For example, the top-level README says:
> -s, --sort <CRITERIA>: Sort by "name", "size", or "date"
OK, does "date" refer to creation date, modification date, access date?
I can understand "size", but does it produce smallest-first or largest-first? It might not matter if... ah, no, there is no -r/--reverse flag.
Can I have more than one "criteria" (since the plural is used)?
Getting answers for such questions now means I have to go read the code in src/args.rs and follow to the implementation of the various functions. And in a few days, when I have the same questions again and I have forgotten the options, I will again have to dive into the code.
Please consider providing a short man page. It documents the "calling interface" to your program and makes it easier to use. I usually start writing one even before implementing the whole thing, to clearly articulate what I expect the program to do.
Fair critique about the documentation - this needs proper attention.
Writing a man page first is a solid approach - it forces clear thinking about the interface before implementation. I'll prioritize adding complete documentation for all options and the plugin system.
The code works, but without good docs it's not truly useful.
While a man page or good documentation is maybe not too intriguing for you I consider it essential for other users to adopt.
Maybe there are new or modern ways to create man pages that can be stimulating for your learning experience?
Thanks for all the feedback! Let me clarify a few things about lla.
The most amazing part of this project wasn't just building another ls alternative - it was the incredible learning journey. Building a systems tool in Rust while implementing a plugin architecture taught me more in a few weeks than months of reading could have.
Yes, it does more than traditional ls, and that's intentional. The plugin system came from scratching my own itch of constantly switching between different terminal tools. Each feature added was a chance to dive deeper into systems programming and Unix internals.
The performance still needs work, and the documentation could be better. But that's the beauty of open source - you ship it, learn from the feedback, and keep improving. Building in public is an incredible way to level up your skills.
For anyone considering a similar project: pick a common tool you use daily and try reimagining it. You'll be surprised how much you learn along the way.
reply