I use Nix and make(1) to develop

> "Uhm, actually" I use Guix...

And there you have it: the fundamental problem. What if I want to port your package to Nix?

In practice, I'm sure it's doable, but you are introducing a lot of overhead and complexity by putting that work into that place.

Here you assume that more people know about make than npm or yarn, which I wouldn't bet on.

Besides, I would guess that every JavaScript developer when jumping on the new project will know how to use npm, just like every Java developer would know enough maven, and adding some supposedly general standard tool on top of already standard tools in that area wouldn't help.

Just my opinion but make is still the best ci/cd tool. I see way too many places with layers of tools and yaml configs and hosted cvs pipelines (that you can't easily recreate locally), when a make file would do just fine if not better.

The tradeoff isn't just about documentation, but complexity. A tedious, manual build process is still tedious and manual if it's self-documenting, but a more streamlined build process without as much documentation might still be less of a burden overall. It's also not like Make doesn't have its own thorny edges too; one person's self-documenting use of a feature is another person's inscrutable magic invocation. If you're working on a team project and already require a certain level of expertise in the ecosystem you're using, it's arguable that using the native build system (warts and all) will be a better tradeoff.

Obviously you haven’t seen > 100 line makefiles. They are a mess to understand and I have no interest in wasting my time to understand what they are doing.

For C(++), I use make and ccache. I can just use `find` to place a naive dependency of every header file on every C file; and, `*.d` files (from clang/gcc): I get nearly perfect incremental builds, without file updates breaking the build, in parallel. Totally bulletproof and works on all the Unixen I care about (Linux, macOS, BSD).

Careful-- there only thing worse than no makefile is unmaintained and outdated makefile full of dark magic and obscure shorthands.

NPM has no concept of dependencies of steps like make has for what people use in "scripts". It is painful to see people doing that all the time and then constructing their commands as long strings, which the tool they use has no knowledge about, using recursive invocation and having to write "npm run" again and again in those long strings, while in a Makefile it is all figured out automatically, as dependencies of steps are clearly stated as such.

It feels akin to handling HTML as a long string and fumbling around in it, as was done in the past in many PHP projects, instead of handling HTML as structured data, an XML tree or similar.

NPM package.json scripts is a Makefile for the very poor. Yes it can be used like that. Should it? When commands start to have prerequisites probably not.

> I think the main/only reason to go out of your way to use `make` as a task runner is its ubiquity.

In fairness, that's a pretty big reason.

I switched to Just for most of my projects. The only thing I miss from Make is the possibility to run the tasks in parallel.

Files with spaces in the name are just a bad idea anyhow, Make is just helping out by making the problem more explicit.

Is this an issue of make, or shell? If we properly quote all variable usage, shouldn't it simply result in quoted values in shell commands, which are then correctly interpreted? Or do you mean when using something with spaces in make in-built functions?

I can't tell if you meant to imply this, but that is the very benefit Nix provides: a guaranteed stable and sterile environment where ./configure, make all, and make install can be run. No more chances.

If you have a configure step it can fail by default if there is anything to specify explicitly. But otherwise it is nice to have some defaults. In my opinion a configure script shouldn't do much in terms of detection. It should not silently enable/disable features based only on libraries being present/missing. By default it should try to use lib a and b, if the user wants they could explicitly opt-in to use lib c without lib b, otherwise let it fail.

That said it all makes it easier to just use config for make that can be edited. For example config.mk included by Makefile. I learned this trick from Suckless.

Once you build a docker image, you can distribute that artifact reliably. But building docker images is highly error prone, at the mercy of non-determinism, various failure modes of package managers, and mutable state from web servers you don't control. In practice, you can't depend on it working without active maintenance and disciplined usage.

With Nix, if it built once, it will build again, consistently and deterministically. It reduces fear of changing things because it just works. You don't have to cross your fingers and hope the build succeeds this time.

What smilliken said. Essentially, with a single flake.lock file, you get build determinism, which is huge. Docker cannot guarantee that... which is, in fact, why distributing Docker images is a thing, instead of just distributing and composing Dockerfiles.

If Dockerfiles were guaranteed to succeed, and Docker hosted a cache of hashed binaries instead of a cache of Docker images (the former is far more efficient than the latter, btw), then all you'd need are Dockerfiles.

Enter Nix (and its flake.nix/flake.lock files).

Nix essentially solves a problem that Docker can't by treating a build as an immutable function with binary-hashed inputs and binary-hashed dependencies and completely controlled environment variables (with a few exceptions and special cases)

On Mac where Docker runs in a VM, "nix develop -c" I think would be faster.

Using nix develop (without -c) to get a development shell has some advantages over docker. It layers over your existing environment (unless you don't want it to) so you can still access things like git from the same shell. With docker you either add it to your build deps or do some stuff inside docker and some stuff outside.

It also builds your environment on demand rather than having to manage the two step thing of building the image and then making sure you're using the right one.

I've found this much more flexible and convenient than anything with docker.