Show HN: I made an ls alternative for my personal use

Original Article ↗ Hacker News Discussion ↗

Motivations for Yet Another ls Alternative

  • Many see building an ls clone as a low-risk “systems Hello World”: good for learning Rust, filesystem APIs, terminal control, and plugin architectures.
  • Some commenters don’t understand the appeal, saying vanilla ls already does what they need and there’s limited room for improvement.
  • Others appreciate experimentation and see value in rethinking everyday tools, even if only for personal use.

Feature Set vs. Unix Philosophy

  • Several compare this tool to exa/eza, lsd, colorls, g, lc, pls, and TUI file managers like ranger and broot.
  • Critics argue many new tools pack in searching, filtering, sorting, git integration, etc., drifting from “do one thing well” and composability.
  • Others counter that Unix philosophy is a means to better UX, not an end, and that coupling some features (like ripgrep does) can be justified.

Performance and Technical Concerns

  • The README claims “optimized for speed”; one commenter’s benchmarks report significantly higher CPU use and slower runtime versus ls on large trees.
  • Author acknowledges performance is a work in progress and plans to optimize.
  • Discussion branches into how ls behaves when piped, TTY-dependent output formats, and the perennial “don’t parse ls” vs. “you can if you’re careful” debate.

Plugins, Extensibility, and Structured Output

  • The standout idea for many is the plugin architecture, enabling community extensions without touching core code.
  • Some compare this to plugin-friendly editors (vim/neovim) and to other extensible ls-likes that support libmagic, custom sorting, and type-aware coloring.
  • A separate subthread explores richer, typed terminal output (hyperlinks, type-aware interactions, JSON/structured data) and shells like Nushell or PowerShell that treat data as tables.

Usability, Documentation, and Adoption

  • Several emphasize the importance of man pages and clear docs, especially for flags like sort criteria and date semantics; current documentation is seen as thin.
  • There’s debate over relying on ubiquitous coreutils vs. installing nicer alternatives everywhere; some prioritize standard tools for portability.
  • A side discussion covers expectations of open-source quality and responsibility, with differing views on how much “production-readiness” users should expect from hobby projects.