Tbh I don't find their comparison to asdf particularly compelling. While the asdf shims have downsides, besides that I think I prefer the more principled and tightly scoped approach that asdf has.
> mise makes heavy use of aliases so you don't need to remember if it's mise plugin add node or mise plugin install node. If I can guess what you meant, then I'll try to get mise to respond in the right way.
I prefer that there is one, correct, way of doing things and my tools not trying to guess what I want. If there are two different commands they should do two different things and it should be clear what the difference is. Keeping track of different aliases is just additional mental overhead to me.
I acknowledge that all this is very much a preferential thing, so I guess if this works for author then more power to them.
If you use asdf, I would encourage you to try my tool. A lot of the work I've done is around things that you probably won't ever think about but in mise it just works the way you want it to so you can get to getting your work done.
The reason people like mise is hard to put in a post because its really the care and countless hours I've put into working through workflow after workflow over and over. Testing things out. Going back on decisions I felt like weren't as good as they could've been. Reading and re-reading code in both my own codebase and asdf's. My niche is building CLIs and I am grateful to be able to work on something people are finding so much value in. Understand mise didn't start last year, I've been planning this project for over a decade while working on other CLIs and dev tools.
Here's an example of one: in mise the shims will fall back to system versions. So if you have a shim for `ruby` but you only use ruby in 1 project without a global set then calling ~/.local/share/mise/shims/ruby will go to the next thing on PATH, so maybe /opt/homebrew/bin/ruby. In asdf, the shim will fail outright unless you explicitly set "system" as the version in your global config.
At the end of the day though, I know not everyone will like mise. I certainly have a particular style of building tools and managing the project that works for some and doesn't for others. Ultimately I think this allows me to build tools that while they may never be universally adopted will be more enjoyed by those that it rings true for. Of course if you don't like it I'd be particularly interested to hear what is is you don't enjoy.
You don't need to keep track of aliases, can just as easily use your "one correct" way and never learn/forget the alternatives, so what's the downside? In general, the overhead of remembering precise tool-specific command is higher that using some common knowledge from other tools you remember that are aliased in this tool
> You don't need to keep track of aliases, can just as easily use your "one correct" way and never learn/forget the alternatives, so what's the downside?
Sure if you work in an isolated bubble and don't ever read the docs, google things, discuss with other people (or llms I suppose these days). But that's not really realistic... In practice you will be encountering the variations all the time, and it'll just add friction.
> In general, the overhead of remembering precise tool-specific command is higher that using some common knowledge from other tools you remember that are aliased in this tool
As polyglot developer I simply don't find that to be the case, small syntax differences are not problem, its far bigger problem when I read the docs and see five similar commands and need to figure out if they are aliases, if there are some subtle differences, and if one of those is the canonical choice.
> people (or llms I suppose these days). But that's not really realistic... In practice..
In practice it's trivial to avoid llms and stuff for such simple tools, `tool -h` is pretty often more than enough. This isn't your generic git cli monstrosity
> small syntax differences are not problem
And this discussion is not about small syntax differences, so this isn't relevant. I was talking about your ability to guess a command because that's the command you use in another tool, e.g., use "install" and not get an error because there is only 1 "correct" way to "add"
> bigger problem when I read the docs and see five similar commands and need to figure out if they are aliases, if there are some subtle differences
or "figuring out" could be as big a problem as simply reading a 5-word sentence till the end "install ... [aliases: i, a]", so this makes no sense as a general point.
> and if one of those is the canonical choice.
why would you care about canon instead of using the one best for you? If in your mental model apps are (un)installed, so you always use `tool u/i`, why would you care if the author thinks add/remove is best?
> mise makes heavy use of aliases so you don't need to remember if it's mise plugin add node or mise plugin install node. If I can guess what you meant, then I'll try to get mise to respond in the right way.
I prefer that there is one, correct, way of doing things and my tools not trying to guess what I want. If there are two different commands they should do two different things and it should be clear what the difference is. Keeping track of different aliases is just additional mental overhead to me.
I acknowledge that all this is very much a preferential thing, so I guess if this works for author then more power to them.
https://mise.jdx.dev/dev-tools/comparison-to-asdf.html