Pretty much my reaction too. Seems like Make, reinvented.

Which is a good thing, as it supports a use case that Make wasn't made for.

What use case is that? I looked over the README, including the parts where it claims to do things Make can't (I don't agree with much of it). I remain unconvinced that it supports use cases Make can't.

It's not that Make can't work as a task launcher, it's that it's not designed as such.

The simple fact that a build target isn't executed if the build file already exists, requiring a workaround to run it, points to the difference in purpose and philosophy. Those little details, together with the more modern design, accumulate to make Just a tool that is simpler to use for that purpose.

Yup. All anyone needs is to learn Make properly once, which can be done from following a simple guide like https://medium.com/stack-me-up/using-makefiles-the-right-way...

sure, let's stop looking for better ways to do things because this one 30-year old way is capable of being twisted into what you need, no matter what it is.

I get the reverence around make but don't blind yourself to potentially better ways of doing things.

I would even go so far as to say that intentionally avoiding new ways to approach these things will necessarily blind you to better ways once they do come along, and I wonder how many good tools have died because "[x] does all I need." (replace "x" with whatever you like.)

Is there really any propriety around this tool when something as abysmal as autotools has to exist to generate the makefiles/etc.?

This simple-ish guide made me realise that make is not as suited to my needs as a mostly web developer, and that just would work better. NPM functions are doing just fine for me now, and some of the routines I'd map to npm commands anyway I don't know how much benefit it would actually bring to me.

Same! The fact that Make is pre-installed everywhere and you can create a consistent interface to tasks across projects is a big win.

I wrote a post about that here: https://rosszurowski.com/log/2022/makefiles

> Make is pre-installed everywhere

No, its not, and Just supports Windows, where that is particularly true.

Make also has a windows version, it just needs to be installed, just like Just.

Okay, but a ton of people are saying “make comes preinstalled on every system” as the reason to choose it over something like Just.

Because, statistically, it is true. Pretty much every POSIX machine under the sun has make available.

GP and GGP were talking about Windows, which is a significant portion of all machines so I don’t see how you can say that’s statistically true?

Just is built in Rust rather than C. Rust is generally nicer to work with and maintain than C libs so huge win there development wise. Feature wise, only see a couple things with Just right now that differentiate it from Make.

I don’t understand how Just being written in rust as opposed to C has anything to do with this?

I'm not sure what you're confused about, maybe you missed the point of this being shared on ycombinator news? Just being written in Rust versus C is part of an open source movement to modernize these old tools and the significance of using a modern language versus an ancient one is better support and features going forward. The reason this tool is currently top voted on ycombinator news is purely because it's written in Rust and of interest to programmers who care about their open source tooling.

Implementation language is not very relevant. If you have to look at the source code of your build tool, you've already lost.

This is a weird opinion to me, but I reckon you're an ops person who doesn't code a lot so I respect not wanting to have to look at code if you're an ops/admin type. Most programmers would grasp the relevance of modernizing their tools and the maintainability and feature gains from it. The open source movement in general is based entirely upon being able to look at the source code of your tools and modify and update them.

I hate to be the bearer of bad news, however your assumption is incorrect. I possess deep expertise in a number of areas, and code flows with ease. Reading code is it's own skill, too. I'm not easily intimidated by any programming language or problem. On the technical front I've done everything from development, SRE, ML/AI, founding a company, being a leader and executive at small and very large companies.. it's all fascinating in it's way. But the most fascinating things I've found in the universe are people.

When something doesn't work as expected, I dive in as deep as the rabbit hole goes to get across the line.

Curious why you jumped to "Aha! They must be an ops person!", will you humor me with an explanation?

Would you throw out sqlite, written in C for a Rust clone?

It is possible to reimplement a relatively easy tool like make, and having learnt from its historical shortcomings it can be better irrespective of the implementation language. But that’s a different point.

Wait until you find out that Rust uses llvm.

and if make is too much for you, if you just need to run some tasks and have no need for managing artifacts, there is always bash function

https://github.com/adriancooney/Taskfile

Because make is dog shit if you need to intertwine make with bash. You have to remember various escaping rules (double $$ signs or not depending on whether you want to refer to a make variable or interpolate a bash variable), tabs instead of spaces that new devs often (quite rightly) get tripped up by, and various other idiosyncracies you can waste hours on.

Why not just have a shell script that you run with ./serve? Even simpler.