possible replacement of asdf

[sassdavid]

Hi @nickjj,

Have you heard about mise, formerly known as rtx?

Check it out at:

• Website: https://mise.jdx.dev
• GitHub: https://github.com/jdx/mise

It's a 'clone' of asdf implemented in Rust with a lot of additional features. It handles runtimes differently, making it much faster than asdf.

All asdf plugins are compatible with mise, and it can be used to install Node without node-build from pre-compiled source. It implements the Node plugin as a 'core' plugin, allowing its use without any additional plugin installation.

Take a look at it, and let's consider leaving asdf behind.

Thank you for these dotfiles and the information they contain.

[nickjj]

Hi,

Thanks for opening this, no I haven't heard of this project before. Although I've found that in practice any slowness related to asdf is related to things like compiling runtimes if no pre-compiled binaries exist for a specific platform. That's a 1-off use case during installation of a new runtime version and I'm not sure how mise would make that process much faster? Have you noticed other cases where asdf is slow to the point where switching to mise makes a noticeable difference?

My main concern would be supporting languages that aren't listed under languages in https://mise.jdx.dev/getting-started.html. For example if someone using my dotfiles has asdf set up to work with PHP, what would that look like for mise?

[sassdavid]

Hi,

Thank you for your prompt response.

It's surprising that you haven't noticed any slowness issues with asdf. I noticed the slowdown immediately upon installation and activation. My bash became slower, and the tools themselves were affected due to the shims. You can find more information about this issue at asdf-vm/asdf#290.

Additionally, there was an issue reported (asdf-vm/asdf#1565) regarding the differences between asdf and mise (formerly rtx). Please review it for further details.

The mentioned languages are highlighted because they are 'core' plugins implemented in Rust. However, you have the option to use asdf plugins. For example:

mise plugins install php https://github.com/asdf-community/asdf-php.git
mise install php@latest
mise use -g --pin php@latest

Feel free to explore mise further.

[nickjj]

It's probably because I mostly use Docker to contain my apps. The only time I use asdf is to run an old version of Ruby / Node for Jekyll. On a Jekyll command that takes 3 seconds to run (incrementally reloading my blog in development), an extra 40ms doesn't make a noticeable difference. It's certainly not noticeable when I do a full blog build that takes 35 seconds.

Technically one of the Vim plugins I use uses Node too, but I don't notice any real delay when opening Vim.

[sassdavid]

Yes, I completely understand.

So, perhaps in your case, there isn't any noticeable or disturbing slowness when using asdf. However, for me, it was quite apparent, both during the prompt loading and when using the various tools, which proved to be distractingly slower.

I genuinely appreciate your dotfiles, and I wanted to bring up this option. It might be useful in the future. Therefore, I am closing this issue now.

[nickjj]

Thanks. If you want we can move this to an open discussion that stays open. Then other folks can contribute to the conversation too. If mise wins in the end and some other folks mention they notice big wins when using it I'd be open to switching over.

[jdx]

just some thoughts from the maintainer of mise—obviously biased but I try to be objective.

The performance problems that mise targets are more around executing runtimes, not installation. (Though there are some exceptions, like python uses redistributable pythons that's orders of magnitude faster to install) For me it's a lot worse than a few milliseconds:

~ ❯ hyperfine "~/.asdf/shims/node -v" "~/.mise/shims/node -v" "node -v"
Benchmark 1: ~/.asdf/shims/node -v
  Time (mean ± σ):     243.5 ms ±  17.9 ms    [User: 23.4 ms, System: 11.0 ms]
  Range (min … max):   225.5 ms … 289.5 ms    10 runs

Benchmark 2: ~/.mise/shims/node -v
  Time (mean ± σ):      36.3 ms ±   2.9 ms    [User: 19.1 ms, System: 5.0 ms]
  Range (min … max):    29.8 ms …  45.4 ms    69 runs

Benchmark 3: node -v
  Time (mean ± σ):      30.1 ms ±   2.1 ms    [User: 20.7 ms, System: 2.6 ms]
  Range (min … max):    23.3 ms …  35.9 ms    68 runs

Summary
  node -v ran
    1.21 ± 0.13 times faster than ~/.mise/shims/node -v
    8.09 ± 0.81 times faster than ~/.asdf/shims/node -v

I noticed that you're using it for a vim plugin. I'm not sure which one or how its loaded, but this could translate into vim being noticeably faster to launch—especially if node is being called multiple times.

You'd also be able to simplify your setup, turning:

. "${HOME}/.local/share/asdf/asdf.sh"

printf "\n\nInstalling node %s...\n" "${install_node_version}"

"${HOME}/.local/share/asdf/bin/asdf" plugin add nodejs || true
"${HOME}/.local/share/asdf/bin/asdf" install nodejs "${install_node_version}"
"${HOME}/.local/share/asdf/bin/asdf" global nodejs "${install_node_version}"

into:

PATH="$HOME/.local/share/mise/shims:$PATH"

printf "\n\nInstalling node %s...\n" "${install_node_version}"

"${HOME}/.local/bin/mise" use -g "nodejs@$install_node_version"

The trajectory of the projects I think is also important, though pros and cons to both projects. I don't think there could be a question that mise is under a far more rapid pace of development. While I try to keep breaking changes to the absolute minimum—they do happen with a project moving this quickly. asdf though has been pretty stagnant with their pace. I have also been far more liberal when it comes to features where they've taken a focus on maintainability—you may see that as a pro or a con.

Lastly, asdf has some supply chain problems they're aware of but trying to solve differently than mise. I've outlined it here and what we're doing to try to resolve them: https://github.com/mise-plugins. It's a little early still, but I think long-term mise will be under less exposure to this problem.

I think it would make complete sense to take a "wait and see" at this point for you but I figured it couldn't hurt to throw my two-cents in.