38 kilobytes of executable isn't small, it's tiny; there's no way exa could get to that level without compromising its featureset or development, and even if you did, you'd just have another ls, and we already have ls.

If it's not small, what would you call it? Medium-sized? Something of that size means "download tens of megabytes of runtime and scatter files all over your computer" to me, and exa's smaller than that.

Self-contained, portable, featureful, etc. There are plenty of other adjectives to say it's not huge or "download tens of megabytes of runtime and scatter files all over your computer".

For me, <64KB is small and <4KB is tiny. But then again, being aware of the demoscene, I've seen what can be done in those size categories... ;-)

I'd be willing to bet dynamic linking would get it much closer to that ballpark and wouldn't compromise the feature set or development.

Good overview and HN discussion of this: https://news.ycombinator.com/item?id=11823949

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 QT statically compiled into everything.

Did you strip both binaries? If I strip rg after compiling it, it shrinks to 2.7MB on Linux. If I strip the distributed binary on Github (which is statically linked with musl), then it shrinks to 2.4MB.

> Imagine what life will be like when we have UI toolkits like QT statically compiled into everything

I imagine Qt will be dynamically linked, so I'm not sure why you'd say that.

Of course, if you want to statically link something like Qt because it makes distribution easier for $reasons, then that's a different story. But that has nothing to do with Rust.

No, should I have to? I'm just looking at the published binary sizes.

> I imagine Qt will be dynamically linked, so I'm not sure why you'd say that.

I said like Qt, as in something similar written in rust. The Qt5 GUI module weighs in at about 10MB, if every gui program included it plus all the other libs then the bloat quickly adds up.

> But that has nothing to do with Rust.

Until rust has a stable ABI that doesn't require everything be statically linked it's a rust problem.

Love the brigading the rust community always does btw. Apparently someone was triggered enough to go through my comment history downvoting.

You don't have to do anything, including publishing misleading comparisons.

> Until rust has a stable ABI that doesn't require everything be statically linked it's a rust problem.

Qt can be dynamically linked into a Rust application. For example, the default is to dynamically link glibc on Linux x86_64.

>Qt can be dynamically linked into a Rust application. For example, the default is to dynamically link glibc on Linux x86_64

Again, it was an example. Show me a similar rust library that can be dynamically linked to like this? A rust equivalent will have to either use a c interface or be statically compiled.

I explained how. Take it or leave it.

> If the size can be reduced then why isn't it done when you publish it?

Because it's not a big deal? The only people who complain about this are people debating holy wars on HN, as if the static vs dynamic trade offs haven't been well understood by now.

> Again, it was an example. Show me a similar rust library that can be dynamically linked to like this?

Rust's standard library.

(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.)

    % du -h /bin/ls
     20K	/bin/ls

    % ls -laF /bin/ls
    -rwxr-xr-x  1 root  wheel  38624 Jul 15 00:29 /bin/ls*