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

Original Article ↗ Hacker News Discussion ↗

A new Rust-based alternative to the Unix `ls` command, built primarily as a personal learning project, has prompted debate over whether such tools meaningfully improve on the decades‑old original. Commenters compare it to other modern replacements (like eza, lsd, pls, and lc), weighing benefits such as colors, icons, plugins, advanced sorting/filtering, and structured output against downsides like performance overhead, fragmented behavior, and deviation from the traditional Unix “do one thing well” philosophy. The exchange also surfaces broader concerns around portability, documentation quality (especially the absence of man pages), and the value of hacking on familiar tools as a way to deepen systems programming skills.

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.