For quite some time, I have gathered this set of Rust CLI tasks that are exactly the same. I have used them as template generators for cargo-generate. This became a problem recently when I was writing a monorepo that had mixed projects (Rust server, Svelte Frontend, and Terraform deployment). This comes at just the right time for me to utilize this without going insane.

Also, I had a not-so-great experience with other builders/managers, including lerna so I love this.

@jdxcode, how long before I can replace Emacs with mise?

I hope never! scope is big enough!

What are you talking about? You don't need to install node for this. It's a self-contained rust binary.

I started using mise back when it was still called rtx. I was a little annoyed by asdf's quirks and having it replicate that behavior while being faster and less intrusive in my shell configuration was great.

Since then, mise has folded in two capabilities that I needed the most: Task Running and Env Vars.

Overall, it has been a fantastic experience for me. I love how the developer has spent a lot of time ensuring compatibility with existing tools while still building future capabilities.

I will add one thing that I knew I needed but couldn't find anywhere was added through the recent backends feature. I do a lot of trust and R development and there are dev tools that I need installed that I don't use as libraries, just the binaries. It was a problem making sure that those dependencies were installed in a new environment. Now, it's just so easy: I list those in my `mise.toml` file, and that ensures they are installed and installable.

The biggest visible boost has been in my shell startup times. Buying a computer after 5 years with 4 times as many cores and it feeling just as sluggish because nvm and pyenv are parsing the same set of bash files reading from disk was not pleasant. Mise actually made me feel, I didn’t just throw the money into a void

I don't understand how people don't notice the massive tax they're paying by using nvm:

    $ hyperfine "~/.nvm/nvm.sh" "mise env"

    Benchmark 1: ~/.nvm/nvm.sh
      Time (mean ± σ):      1.722 s ±  0.032 s    [User: 0.064 s, System: 0.112 s]
      Range (min … max):    1.684 s …  1.805 s    10 runs
     
    Benchmark 2: mise env
      Time (mean ± σ):      13.4 ms ±   5.7 ms    [User: 10.0 ms, System: 21.3 ms]
      Range (min … max):     9.4 ms …  42.2 ms    29 runs
      
    Summary
      mise env ran
      128.14 ± 53.94 times faster than ~/.nvm/nvm.sh

100x is definitely something you'll notice

EDIT: for some reason in discord we're getting very conflicting results with this test. idk why, but maybe try this yourself and just see what happens.

I switched to https://github.com/Schniz/fnm a while ago and it’s been fantastic. I also bake it into all of our Packer images at work.

I built my own version on nvm (called nsnvm, for "Nuño's stupid node version manager") to solve this. You can see it here: https://github.com/NunoSempere/nsnvm Absurdly fewer features (and might break npm install -g), but very worth it for me for the reduced startup times.

I prefer GitHub.com/tj/n. It's really nice.

I notice. It's awful.

Count of grey hairs on my head and face is only increasing so I'm gonna be that guy:

Nix/NixOS and Guix are two solid solutions to the problem, because they spin up completely independent, immutable, environments. You don't need to mess around with shell hacks to swap out the correct `npm` or `ruby` binary based on a string in one of several dozen dotfiles.

More or less python-style virtual envs on steroids where it's not just python stuff that isolated, but the entire setup. All your tools, all your config. Throw in `direnv` so you can make your editor and GUI tools aware of it.

The only initial headache is making sure the package is available to pull in -it's easy when it's distributed, but when tools are published through NPM or RubyGems or Crates or just on github that you have to run `go install` to get, then it's a bit of faff. But the same faff that distro managers have keeping, say, debian's sources up to date.

I feel like nix has been thoroughly discussed in this post already, so you're not the only guy.

> You don't need to mess around with shell hacks

Shell integration is optional, you can use `mise en` just like `nix-shell` or `nix develop`. You could also just invoke commands/scripts through mise tasks or mise exec.

> based on a string in one of several dozen dotfiles

The "Idiomatic" files like .nvmrc, .python-version, etc are supported but most people just use a mise.toml, which (a bit like flake files) contains all the config for the environment.

> but when tools are published through NPM or RubyGems or Crates or just on github that you have to run `go install` to get, then it's a bit of faff

And this is what mise excels at: `mise use npm:cowsay` or `mise use ubi:junegunn/fzf`

I think Nix/Guix are great, but also terrible. For me today, it's not worth the pain.

I have used GitHub Copilot since it came out. I mostly use it for code explanations and writing tests.

My experience is that you can't trust it completely for obvious reasons, so you need to know what you are doing before you can rely on these tools.

I have tried Amazon Q and was severely disappointed.