4 ms·

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 les

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.

tecoholic 2y ago
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
- jdxcode 2y ago
  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.
  - paulddraper 2y ago
    I notice. It's awful.
  - porridgeraisin 2y ago
    I prefer GitHub.com/tj/n. It's really nice.
  - httgp 2y ago
    I switched to https://github.com/Schniz/fnm 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.
  - NunoSempere 2y ago
    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 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.
ljm 2y ago
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.
- syhol 2y ago
  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.

tecoholic 2y ago

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

jdxcode 2y ago
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.
- paulddraper 2y ago
  I notice. It's awful.
- porridgeraisin 2y ago
  I prefer GitHub.com/tj/n. It's really nice.
- httgp 2y ago
  I switched to https://github.com/Schniz/fnm 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.
- NunoSempere 2y ago
  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 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.

ljm 2y ago

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.

syhol 2y ago
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.