Eza: A modern, maintained replacement for ls

> For a more useful comparison, with actual source dependencies and build target:

Makefile:

     GO_FILES = $(shell find . -type f -name '*.go')

     ./myapp: $(GO_FILES)
         go build -trimpath -o $@

     .PHONY: build
     build: ./myapp

 Taskfile:

     tasks:
       build:
         cmds:
           - go build -trimpath -o ./myapp
         sources:
           - '\*/*.go'
         generates:
           - ./myapp

Even in this example, what is PHONY needed for?

    GO_FILES = $(shell find . -type f -name '*.go')

    ./myapp: $(GO_FILES)
        go build -trimpath -o $@

Honestly, it's still simpler to read.

> Makefiles are incredibly terse, but that's not an advantage.

Brevity is not why I prefer Makefile syntax over YAML, readability is. The minute you start trying to do anything large in a YAML definition you're going to need special editor help to keep track of indentation, and even with that, a large tree is still going to be lost off-screen because the context of any node in the tree depends on seeing the lines immediately above.

With Makefiles, any node in the tree has immediate context on the same line (the dependencies) which makes it very readable to me. I really prefer:

    target: dep1 dep2 dep3 dep4

compared to:

    tasks:
      dep3:
        cmds:
          - ...
        sources:
          - ...
        generates:
          - ...
      dep2:
        cmds:
          - ...
        sources:
          - ...
        generates:
          - ...
      dep1:
        cmds:
          - ...
        sources:
          - ...
        generates:
          - ...
      target:
        cmds:
          - ...
        sources:
          - ...
        generates:
          - ...

yes, that's exactly what I said here:

https://news.ycombinator.com/item?id=41039675

Eza: A modern, maintained replacement for Exa ;-)

  >   fd - find alternative
  >   rg - ripgrep (grep)

NOTE OF WARNING:

BY DEFAULT these ignores anything included in your `.gitignore` folder. So if you think it is a straight find replacement, you'll likely be surprised. fd discussion here[0]

Just make sure that when recommending people these tools that this is clear because if they don't read the docs (lol who does) they'll miss this part.

This is a pet peeve of mine. I wish the people that make these replacement coreutils (and others) would leave the defaults as very similar to the original tool. I do really like the new functionalities but if you market it as "an alternative" ("It is a simple, fast and user-friendly alternative to find") then they should respect the defaults of the original because it reduces new user surprise. I mean aliases exist... So it is better to have in your ~/.${SHELL##*/}rc file to have `alias fd='fd --ignore'` than `alias fd='fd --no-ignore'`.

Side note/pro tip: use `\command` if you want to use an unaliased version. An example of this is that I have `alias grep='grep --color=always --no-messages --binary-files=without-match` but this can sometimes be problematic because the color option can change the character representation so if you pipe this into `curl` you will get errors. This is not the case in all piping, but it is a shocking and confusing experience when you first encounter it. You can validate this by `echo "Hello world" | \grep --color=always "Hello" | hexdump` and then `!!:s^always^never`

[0] https://github.com/sharkdp/fd/issues/612

I’ve never looked at a datetime and thought to myself “if only I knew how long ago that was.” Are there really people like that?

And actually, if I saw the date of “2023-12-07,” knowing it was last December actually gives me more information than “eight months ago” — because I know that means around Christmas time last year, and I know what other things happened last December, such as what features we were launching, who the product manager was at the time, etc. If you just shouted a random number of months ago, I would then have to stop and think about the answers to those questions. Lots of my memories could be placed in an approximate month or at least a season, and those never change after the fact. Relative dates are constantly changing and my memory does not increment all its records every month (e.g. “I’ve now worked here 9 months. I’ve now worked here 10 months.” But I can tell you the month and the year I started working here.)

Relative dates are definitely a case of “just because we can do this doesn’t mean we should force everyone to use it”