Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exa, a modern replacement for ls

the.exa.website

Post reply on HN
Print view View original

241–250 of 420 posts

Re: Exa, a modern replacement for ls

#241

Post by vacri »

Houshalter wrote: post #82
blunte wrote: post #68

Earlier quoted context omitted.

I agree. Relativity is important - uniform units.

You would never say that you are 0.0018 kilometers tall. Using sane unit sizes is important. If two files are orders of magnitude different in size, it's easy to tell that just by the units. As opposing to counting the number of digits, which is tedious and error prone. If they are similar, then it's easy enough to tell that also. E.g. 1 GB vs 995 MB.

> You would never say that you are 0.0018 kilometers tall. Using sane unit sizes is important.

Ah, but does "this tool" (whichever tool) mean GB or GiB when it says "GB"? As the prefixes get larger, the difference between powers-of-ten and powers-of-two prefixes gets significant.

Re: Exa, a modern replacement for ls

#242

Post by xelxebar »

kbenson wrote: post #176
khedoros1 wrote: post #154

Earlier quoted context omitted.

Well, right, 180cm would be a customary way to show that (probably wouldn't be shot for saying 1.8m either). And 32GB for an SD card, or whatever. But then you run into the case that the "32GB" SD image that you just dd'd won't copy to another card of the same nominal size, because it turns out that the destination card has reduced capacity due to 100KB of bad sectors, or something. Or your file went from 2100 bytes…

I think what's really in discussion here is what the default should be. ls was originally conceived and implemented in a period when all the files you would be dealing with could be measured in bytes easily, and would almost never be over four digits. Many common files today (any MP3, most word processing documents, almost every image except for thumbnails, etc) are nine or more digits, and at that level it's very ea…

Maybe we could split the difference between precision and readability by using scientific notation?

How does 524404648 vs 5.24404648e8 look?

Re: Exa, a modern replacement for ls

#243

Post by Dowwie »

cytzol wrote: post #202
yegle wrote: post #178

Earlier quoted context omitted.

Writing `ls` is the first thing I do when learning a new language.

Thanks for the kind words, everybody. exa was my first Rust project and it just grew and grew.

Would you consider reflecting and writing about your experiences using Rust?

Re: Exa, a modern replacement for ls

#244

Post by userbinator »

krat0sprakhar wrote: post #148

Wow, the comments in this thread are quite harsh. Even though I might not use it, this looks like an awesome project - kudos to the author for finding (& implementing) ways to improve something as mundane as ls. I've long been stuck on finding a suitable (perfect?) project idea to play with Rust but exa is making me think through again! Thanks for sharing this and also for your screencasts. I'd definitely spend a laz…

Wow, the comments in this thread are quite harsh.

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.

Re: Exa, a modern replacement for ls

#245

Post by hayd »

flukus wrote: post #164
simias wrote: post #103

Earlier quoted context omitted.

Rust links all its runtime statically by default. Your /bin/ls is probably dynamically linked to libc and a few others. That being said that the argument of size is a bit silly to begin with, especially for a 3MB binary.

> That being said that the argument of size is a bit silly to begin with, especially for a 3MB binary. For a single app, sure it's no problem, but what about when the thousands of other programs in bin introduce similar levels of bloat? Another one is ripgrep, weighing in at 5MB compared to greps 204kb. And this is just for fairly simple command line tools, Imagine what life will be like when we have UI toolkits like…

The performance difference between grep and ripgrep is stark, ripgrep is blazingly fast, isn't that worth some "bloat"?

Re: Exa, a modern replacement for ls

#246

Post by emodendroket »

hk__2 wrote: post #75
otterpro wrote: post #32

It feels like swiss army knife of 'ls' that tries to do everything in one, and I hope more features are added, such as showing directory size, which would be a killer feature. I hate using 'du' or 'ncdu'. I installed in Ubuntu (and WSL) by downloading the zip file and also 1 dependency by `sudo apt-get install libgit2-24' Edit: It's also fast, and I'm beginning to think Rust is really good for making speedy commandli…

> I hate using 'du' Why? On the other hand, I like to have small tools that do one thing and do it well, and that you can combine to do more powerful things. Personal preference, I guess.

I think in a lot of cases it's kind of nice to just get this all in one command.

Re: Exa, a modern replacement for ls

#247

Post by burntsushi »

hayd wrote: post #245
flukus wrote: post #164

Earlier quoted context omitted.

> That being said that the argument of size is a bit silly to begin with, especially for a 3MB binary. For a single app, sure it's no problem, but what about when the thousands of other programs in bin introduce similar levels of bloat? Another one is ripgrep, weighing in at 5MB compared to greps 204kb. And this is just for fairly simple command line tools, Imagine what life will be like when we have UI toolkits like…

The performance difference between grep and ripgrep is stark, ripgrep is blazingly fast, isn't that worth some "bloat"?

Small correction: the performance difference between ripgrep and GNU grep on single large files isn't that great for common use cases. For some more complex cases involving Unicode (and specifically, predominantly non-ASCII files), ripgrep can do a lot better.

(That statement changes a lot if you're looking at another grep like BSD grep, or if you're directly comparing `grep -r pattern` with `rg pattern`, which is always subject to caveats, because the latter is doing some guesswork and parallelism where the former isn't.)

Re: Exa, a modern replacement for ls

#248

Post by LASR »

cytzol wrote: post #116
arkitaip wrote: post #36

Earlier quoted context omitted.

The more design elements you add - colors, type, graphics etc - the more distracting the design get and the more conflict there is between the design elements. By colorizing everything here, nothing is important anymore. It's just poor usability and design.

(author here) You know what's funny? Every time I have to use ls, I'm so used to seeing the colours that I have so much trouble finding anything. Which column in the permissions is group-read? I can just scan for the green one. Which file in the listing am I supposed to be looking at? I just look for the one with the yellow underline. Colours have familiarity to me in a way that letters and words do not -- if I expec…

Ignore what they all said. It's proven that adding 3 dimensions of color means the information entropy is at least trippled.

If you think about the terminal as a computer interface, then it's pretty obvious that we're bandwidth limited by how much information you can fit onto the page. Any amount of improvement in that bandwidth are certainly welcome changes.

Niceties like having color-coded file sizes and filetypes will seem incredibly obvious in hindsight.

The naysayers today are the same people who were outspoken that a text editor with color syntax highlighting was "poor usability and design". Well then why the fuck does every single modern text editor today colors every single word and displays them in different fonts and styles?

You think these very people don't use syntax highlighting in their editors and explicitly turn them off? They should be denied from using them and rightfully so. But they will naysay and then utilize to their sole benefit, the very things they were so opposed to.

You can be assured, they are myopic morons, barely able to internalize what they see ahead of them, let alone envision with an open mind, the possibility that your fantastic work might actually benefit them while costing them nothing.

Colors are poor usability and design? Nope. Next? You're colorblind? Well, fuck you right in your colorblind eyeball sockets. Nobody gives a fuck about you. You deserve it. It brings me great joy in knowing that you are colorblind. Your life must be unfairly shitty isn't it? Great joy. Warms my heart. Next? 'exa' is too hard to type? Then don't type. Don't do anything at all in fact. You're too lazy and useless to accomplish anything worthwhile anyway. Stop consuming oxygen and occupying space. Better for everyone.

How about those points for counter-criticisms?

It's the nature of the distributions of populations that you will always find these people wherever you look. Gladly, they are easy to ignore. Listen only to those who offer constructive criticism and carry on with doing fantastic work. It is certainly appreciated by the other vast majority of people who are silent and greatly benefit from your work.

I've completely replaced ls with exa with an alias. It's a tool that I've recommended to every one of my coworkers along with fish shell. Now I only wish I had other posix tools of the same quality. Any chance you're writing other tools too? Would kill to have a total posix tools replacement with the same quality as exa.

Re: Exa, a modern replacement for ls

#249

Post by userbinator »

Houshalter wrote: post #82
blunte wrote: post #68

Earlier quoted context omitted.

I agree. Relativity is important - uniform units.

You would never say that you are 0.0018 kilometers tall. Using sane unit sizes is important. If two files are orders of magnitude different in size, it's easy to tell that just by the units. As opposing to counting the number of digits, which is tedious and error prone. If they are similar, then it's easy enough to tell that also. E.g. 1 GB vs 995 MB.

If two files are orders of magnitude different in size, it's easy to tell that just by the units. As opposing to counting the number of digits, which is tedious and error prone.

I disagree; what's easier, spotting the biggest and smallest of these at a glance:

        6,677,967
        5,916,109
        7,164,551
    3,745,059,597
            3,175
        4,194,304
        3,550,137
or these:

    6.37M
    5.64M
    6.83M
    3.49G
    3.10k
    4.00M
    3.39M
If they differ by orders of magnitude, then the difference is visually obvious when the full digits are printed out --- sticking out like the proverbial sore thumb. If they're compressed into units, you have to do some more mental multiplication and comparison.

Re: Exa, a modern replacement for ls

#250

Post by LASR »

arkitaip wrote: post #36
general_pizza wrote: post #17

This is heavily influenced by personal taste, but I don't understand the value of having so many elements of the output colorized. File type seems a useful case, everything else in the output of `exa -l` just looks distracting to me. Just my 2 cents.

The more design elements you add - colors, type, graphics etc - the more distracting the design get and the more conflict there is between the design elements. By colorizing everything here, nothing is important anymore. It's just poor usability and design.

Tell me. I am curious to know if use a text editor without syntax highlighting.

Seems to be the case that there is no modern text editor that doesn't color every single word. Must be so hard for you now that you're forced to use these tools with such "poor usability and design". How do you even manage?

Post reply on HN