When I was primarily using Python, I didn't really "get" Mise. Uh, that's what we have uv for! But it really shines when using things like Node where you want a specific version in each directory, and also want common entrypoints like `mise build` or `mise test` in every repo, regardless of its language(s).
Don't get me wrong: I also adore Just as a task runner. It's what got me off of Make, which is incredibly powerful but somewhat lacking in the DevEx department to say the least. It's probably more "powerful" than Mise's tasks. However, Mise's combination of really good — not astounding, but really good — task runners plus all the tool management stuff is unbeatable for the things I work on.
The biggest jump was from Make -> Just. Just -> Mise was minor in comparison, although enough to persuade me.
Just has a lot of UI/UX improvements over Make, like a way to list available recipes, convenient ways to define command-line parameters to recipes, consistent and easy syntax, and a whole lot of predefined functions and variables to cover common use cases like finding the number of CPUs on the current system, manipulate strings, etc. It doesn't do things that Make can't do, because Make can do anything a shell script can if you don't mind wrestling it into submission. It just does those things much more easily.
But it still has a few warts. Recipes look a lot like a shell script, but they're evaluated separately line-by-line, so you can't set a variable on one line and then read it in another. There are workarounds, but that's the default behavior. And a lot of the time when I'd want a task runner, I also want an environment manager (like uv or cargo or node/npm), so bundling those together matches my workflow better than managing those separately.
I have zero bad to say about Just. It's freaking awesome. If Mise disappeared, I'd go back to using Just. I just prefer Mise right now.
Make and Bazel already exist. Just and Mise and other options don’t need to reinvent that wheel. My last employer used Bazel and I liked using Mise as a wrapper around it so that `mise test` invoked the complex command line to run all the tests, kind of like a set of shell aliases that only affect that one repo.
Same here. The unintuitiveness has caused three separate teams/project to remove all my Makefiles and port them back to bash scripts, rake tasks or stuff like that.
Simply because for most developers it was faster to just whip up a bash script than to modify the Makefile and understand why their change did not do what they expected it to do.
Hell, i've been dabbling in Makefiles for at least 25 years and still have to look up the weird mapping expressions when for some reason there's the "nothing to be done" or "No rule to make target `xxx'".
Its only killer feature is that it's everywhere, ready to be used by any brand new developer without any work. While "Mise", Just or many of the other replacements need stuff installed and/or setup.
they're literally just bash scripts so you don't need mise to run them. I've heard several users have setups where they have people with and without mise running them.
Nope.. it makes perfect sense if you stop misusing what it's intended for "Make file" as its purpose is to make files. They can be made using a compiler or other scripts, and as it supports files for its dependency tree.
It does not make perfect sense. It’s nearly 50 year old software and its design shows it. The basic concepts are perfectly reasonable, but the grammar is not what someone would invent today (see: Bazel).
And until recently-ish, there wasn’t a great alternative that let end users run the equivalent of `make build && make test`, but without using Make. That’s why so many people abused it so: it seemed so close to being handy and convenient. And then someone comes along and runs `touch test` and `make test` doesn’t run tests anymore because no one knew they had to label that target as PHONY.
That’s the kind of stuff that got me all-in on Just from the beginning. It “feels” kind of like Make in the nice ways, but optimized for scripting instead of for building C projects. What a breath of fresh air! And as mentioned elsewhere, for me, Mise came along right behind it and gave us do-everything tool that’s nearly ideal for the kinds of non-C projects I work on now in Rust, Python, and TypeScript.
When you’re using PHONY, you’re using the wrong tool for the job imo. (That means most people)
Just is a task runner, doesn’t do file dependencies / “derived files”
Make is the exact opposite. It’s completely based on files, and their derivatives.
Make will (well should) skip already compiled files, speeding up compilation if you’ve only changed 1 of 100000 file into ann object instead of waiting an hour, and go straight to linking.
Just is nice. But they are two different tools, that just happen to share the fact that they have some sort of dependency tree.
The tooling is 40 years old. It’s been long over due, but it’s ubiquitous.
Taskfile is so much better. mise is what actually got me to start switching everything to Taskfile instead of Makefile as mise easily handles bootstrapping Taskfile and anything else you would need.
Had been using make for simple tasks for ~8 years and just got tired of how limiting it is.
Yeah I love just, but getting the correct environment in a just task can be messy, even loading a virtualenv is annoying. I've also switched to mise for this reason
When I was primarily using Python, I didn't really "get" Mise. Uh, that's what we have uv for! But it really shines when using things like Node where you want a specific version in each directory, and also want common entrypoints like `mise build` or `mise test` in every repo, regardless of its language(s).
Don't get me wrong: I also adore Just as a task runner. It's what got me off of Make, which is incredibly powerful but somewhat lacking in the DevEx department to say the least. It's probably more "powerful" than Mise's tasks. However, Mise's combination of really good — not astounding, but really good — task runners plus all the tool management stuff is unbeatable for the things I work on.