I wonder if a lot of that has to do with how it's being "marketed" --- it might just be me, but whenever I see "modern" being used to describe something, it evokes the negative connotations of being trendy, fashionable, boring, vapid, fleeting, style-over-substance that's all too common with software today (Windows' "modern UI/Metro" being one of the first examples to come to mind); not exactly the right sentiment for promoting a tool that's supposed to be long-lasting, foundational, and practical.

Perhaps if the title didn't contain "modern", the discussion here would go in a different direction.

Religion... never cared for it. Re-invent the whole crappy (though still less crappy than alternatives) Unix command line, I say.

I like the ideas in this tool, but it's very end-user oriented and by being written in Rust with stuff like minor Git functionality built in, definitely not as general purpose as a command like plain old `ls`.

I doubly agree for reinventing fundamentals or attempting to. To be fair, given how resilient unix tools have been, this following and to some extent the harshness is to be expected, I think

As for why anyone might feel aggrieved about replacement of core Unix services, my mind immediately drew a (possibly unfair, but emotionally comparable) parallel with systemd.

Why not? I would.

One could sometimes use find(1) of course, but it has different semantics and output to ls unless you jump through some very silly command-line hoops that will make you say "should've just used ls".

As for the stat(1) program, which might be an alternative for individual files, it is not standardised, is not portable, and is in fact totally incompatible between GNU coreutils and BSD userland (including Mac OS).

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls...

"As with many of the utilities that deal with filenames, the output of ls for multiple files or in one of the long listing formats must be used carefully on systems where filenames can contain embedded white space."

POSIX is such a system. If you try to parse the filenames output by ls, it will break when you encounter a filename with whitespace in it. Use a shell glob instead—it will actually work right.

In the meantime, I recommend you try deleting /bin/ls from your system and then filing bugs against everything that breaks.

  touch 'file with spaces'
  for file in $(ls); do
    rm -- "$file"
  done

Now do this:

  touch 'file with spaces'
  for file in *; do
    rm -- "$file"
  done

  ls -Q

  touch 'file with spaces'
  for file in $(ls -Q); do echo "$file"; done

  "file
  with
  spaces"

For me, when I see people waxing poetically about the unix way and the old, crufty, POSIX userland, it's all about cargo cult, "that's how things have always been", minimum viable progress while keeping compatibility, and heritage-over-substance.

`grunt test`.. ooh, so pretty and creative! `grunt test > test.out`, wtf, why is my file full of control character bullshit?

exa was my first Rust project and it just grew and grew.

It would also be nice to see files owned by different users and some of the git functionality.

ls is a gold standard but that doesn't mean alternatives aren't interesting. Especially as a FOSS project in rust I find it fascinating.

Sad to say I'm here years later and I still haven't even implemented Tetris once in anything.

Typing commands like 'ls -ltra' are already muscle memory to me and that takes effort to change.

oh wait, I know what behaves exactly the same way: ls