Hacker News Reader

Comment by justin_oaks | Hacker News Reader

As someone who uses neither Just nor Make, I'm trying to understand the value proposition.

From what I can tell, Just accomplishes what a set of scripts in a directory could also do, but in a more ergonomic fashion. Since the justfile is a single file, you're not cluttering up your directory. You don't have to look for all *.sh files, but can instead do a "just --list". And using "just target" is probably easier to type than "./target.sh" since the just version has no punctuation.

What are some of the other benefits of Just that makes it superior to "a set of scripts in a directory"?

View on HN

They are both directed graphs that support dependencies, i.e. if you run `make a` or `just a` and they depend on b and b depends on c, both tools will build c first, then b, then a.

What often happens is that people should use `make` (or `just`), but don't, and instead end up writing a poor replica of `make` as a custom python script for example.

And then that python script perhaps shells-out to a subprocess because you can't run something in python directly as a lib, so now you have to import and invoke subprocesses, and so on. Building and deploying a static website using just or make is 4 lines.

This should be in their README. After looking at the repo and some of the comments here, yours was the moment I went from “what exactly is the value prop?” to “that could be useful for me”

"Just accomplishes what a set of scripts in a directory could also do, but in a more ergonomic fashion"

That's exactly the value proposition here. It's a small quality of life improvement, nothing more.

Don’t forget discoverability - writing «make» and whacking tab gives you a nice menu of what can be done with the Makefile. (Just, too.)

But any shell that tab completes make targets should also tab complete executables? Just write ./scripts (or whatever) and whack tab.

I don’t know where to start when the script is in ./Scripts/ or ./tools or ./bin or ./shared/tools. Make has a convention that its file is called Makefile. Just has Justfile. Easy to find. Justfile - here I don’t even have to find it, the «just» executable will search up the directory tree.

Most people know about scripts and what are for. Most people don't know anything about just or what a "Justfile" is.

Most people with a programming or Unix sysadmin background know about Make and what it is for (i.e. compiling source code, plus building and installing system tools).

Knowing that 'Just' is an alternative to Make for running project utility scripts, it may gain popularity and become as well known.

I can't defend Just but everyone on UNIX should know what a Makefile is. Make is a standard. Scripts are just a mess.

I'm not sure `make` is any less of a mess, to be fair. Especially when you're trying to use `make` for general project automation rather than the standard set of build tasks.

Then this is good, but hopefully scope creep doesn't creep in.

I'm not a software developer, but a scientist, and eventually like 5 shell scripts fill a directory. Having them all be in one place sounds neater and easier to document and come back to a few months later without needing to either open up each individual file to read its own comments or to make a separate readme file, seems good for small projects.

You can also run it from any subdirectory as if they were in the root of a project (it searches the parents for the nearest justfile). E.g 'just build' from /proj is the same as when it is executed from /proj/lib1/module1/ without having to think about what the relative path should be.

That sounds like one path traversal bug away from a bad idea.

obviously ginger snark. this is also how cargo works.

Because task runners come from the lineage of build systems, I (previously) would have thought that smart management of dependencies was a critical feature, especially skipping outputs whose inputs haven't changed, so that tasks can be run efficiently. Make and rake both do this.

But I guess, enough of the time, what people want is just a nice tidy way of organising tasks to run. Not drastically different to a set of shell scripts, but organised differently, with a few extra features and less boilerplate per task.

It isn't anything revolutionary, just helpful. I think of it like a lightweight framework for writing shell scripts.

Job pipelines - it's easy to say that the build-release step requires the test step. Admittedly this is still possible in a shell script, but it is either messy (folder of helper scripts?) or requires code duplication.

You know shell scripts can have functions right?

And nice stuff like command/options parsing + nice help messages.

Just has pretty ergonomic support for argument parsing [1] and help messages [2]. You're right about functions of course.

1: https://github.com/casey/just#recipe-parameters

2: https://github.com/casey/just#documentation-comments

> Since the justfile is a single file, you're not cluttering up your directory.

You can do the same with any other scripting language, because with most popular languages it's quite easy to handle cli-parameters on that level.

And using a single messy file is usually not a good pattern. But on the other side, "just" comes with builtin tab completion which you would not get for any random script out-of-the-box. And if you are only using half oneliners or very short scripts, the messiness of a single file does not matter that much. Though, how well this will scale over time is a different topic.

> And using a single messy file is usually not a good pattern.

I find my Justfiles rarely ever get large enough to become messy, and then I just factor out the large tasks as scripts and it's all nice and tidy again. Almost all of my projects with a Dockerfile have docker-build and docker-run-local just tasks and those are pretty much always one-liners, and usually that's as complex as it gets. I treat Justfiles more like runnable readmes than a framework for homebrew build systems; if I need a proper build system, I'm probably going to invoke it via a one-liner in a just task.

https://github.com/casey/just#recipe-parameters

Accepting arguments alone seems to be a pretty big value add.

It's nice you don't have set it up yourself, but it's hardly difficult to do in a shell script.

I think the more reasonable comparison is with Make.

Variables can be set on the command-line: https://www.gnu.org/software/make/manual/make.html#Overridin...

  $ make HOST=dev1.example.org deploy

Environment variables are also available in makefiles.

Uniform interface that abstracts over commands? Nice when you have either bad command / build system or multiple in same project?

Dependencies.

Reply on news.ycombinator.com