> Many popular tools are much more complex to install
I'm curious which dev tools you're using aren't installable with standard mise backends. 99% of dev tools I use don't require a plugin.
> (more painful than, say, an asdf plugin)
You can still use asdf plugins, I could use mise to install an asdf plugin right now with one line `mise use asdf:raimon49/asdf-hurl`. The mise registry is just a convenient list of aliases, even if it doesn't accept new asdf plugins, you don't need it to.
As Larry Wall said "make easy things easy and hard things possible"
There is a good chunk of overlap but mise predominately pulls from github releases artifacts/assets and pixi uses conda packages. While mise can use conda packages, the mise-conda backend is still experimental. I don't think github releases or conda packages are better than the other, they both have tradeoffs.
Pixi is very python focused, it's both a tool manager and a library dependency manager (see uv/pip). Mise considered library dependency an anti-goal for a long time, while I don't see that on the website anymore I haven't seen any movement to go into that space.
You start with the cleanest most minimal config you can get away with, but over the years you keep adding small additions and tweaks until it becomes a massive behemoth that only you will ever understand the reasoning behind.
Do these scripts need to be productionised? I prefer working in an environment where efficient sharing of knowledge and solutions is encouraged, rather than framed as a burden of responsibility.
Given the choice between starting with an almost-working script or starting from scratch, I’ll take the former, it might save a few hours.
My colleagues and I don’t do this 100% of the time, but I never regret it and always appreciate it when others do.
My gut reaction is to rush to the comments to shill my favourite task runner ( mise tasks[1], now with shell aliases[2]!) but pushing past that, the core idea of writing scripts in a file rather than a shell prompt is a great nugget of wisdom. But I disagree with this bit:
"I want to be clear here, I am not advocating writing “proper” scripts, just capturing your interactive, ad-hoc command to a persistent file."
What's the difference? Why not version control it, share it with colleagues. Imagine writing a unit test to test a new feature then deleting it when done, what a waste. Ok it's not exactly the same because you aren't using these scripts to catch regressions, but all of that useful learning and context can be reused.
I don't think the language you use for scripting is too important as long as the runtime is pinned and easily available on all engineers machines, perhaps using a toolchain manager like... mise[3].
My main problem with matrix is that it feels sluggish. I'm told the experience can be improved by running your own homeserver so I'll be trying that sometime this year.
Mise started out using the same plugins as asdf, mostly focused on adding performance and usability improvements. Over time it added more features and security.
Most tools are now directly fetched from github releases without the need for random shell scripts (which is what asdf plugins are).
It also grew to be a task runner and environment manager. At first you might think this is scope creep but they're both opt in and very elegant additions. I don't want to ramble but let's just say they've solved real problems I've had.
I'm a fan of it, and I can't think of a reason why I would use asdf over mise. Its real competition is nix (+devbox/devenv/flox), devcontainers, and pixi.
Frontend churn has chilled out so much over the last few years. The default webapp stack today has been the same for 5 years now, next.js (9yo) react (12yo) tailwind (8yo) postgres (36yo). I'm not endorsing this stack, it just seems to be the norm now.
Compare that to what we had in the late 00's and early 10's we went through prototype -> mootools -> jquery -> backbone -> angularjs -> ember -> react, all in about 6 years. Thats a new recommended framework every year. If you want to complain about fads and churn, hop on over to AI development, they have plenty.
I've been fighting the git CLI for over a decade and I've recently picked up lazygit so I can relate to this post. A good TUI has made git a joy to use and when I did try to pick up jj last year it seems like too much learning for too little gain.
I think git will be "good enough" version control for many years to come.
HOCON is so overlooked but an almost ideal config language in my eyes. The only element I'm not 100% on is unquoted string values (the norway problem but not quite as bad since there isn't no/yes booleans), but even thats not too bad.