Get the top HN stories in your inbox every day.
banseljaj
tecoholic
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
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
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.
httgp
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.
NunoSempere
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.
porridgeraisin
I prefer GitHub.com/tj/n. It's really nice.
paulddraper
I notice. It's awful.
ljm
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
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.
aaronbrethorst
I recently switched to Mise for all of my JS, ruby, python, and java sdk management needs, and I’ve been delighted with it so far. Not having to install RVM, NVM, some toxic brew of python installers until I get a working python environment, and SDKMan has been such a breath of fresh air.
Zaloog
`brew install uv` and no more python troubles occur
syhol
`mise use uv`, there, I fixed it for you.
Mise actually has a great integration with uv, like auto venv activation.
semi-extrinsic
I think uv has auto venv activation and workspaces and stuff, now that uv is the official successor of Rye?
aaronbrethorst
Ah, from the Astral folks. Right on, I'll check that out sometime.
Maybe on my work laptop, which resembles this xkcd classic: https://xkcd.com/1987/
rtpg
uv is its own thing, but direnv + `source .venv/bin/activate` is straightforward nowadays.
Direnv has saved me so much pain nowadays
faster
Why `source .venv/bin/activate` with direnv? I use `layout python` in my .envrc and direnv activates the venv on entry to the directory.
rtpg
`layout python` means that the venv is managed by the layout script in direnv, but when sourcing manually I can create it with uv (or pyenv, because I sometimes need to pin the python version) and then just add the source line.
`layout python` is great when that just works. I have trouble juggling various Python version effectively with direnv's layout script (I _know_ I'm doing something wrong, but I can just set up a virtual env as a one time operation so...)
(I also like sourcing bceause I know _exactly_ what's happening, as I know more about the activation scripts than the layout script direnv provides. But that's just a personal thing)
goku12
I like direnv too. But if you're not planning to use uv, you might want to give pipenv a try - the officially recommended tool for the purpose. Pipenv has just one command to create a virtual environment and install packages. And while pipenv can handle traditional requirements.text file, it's real strength is pipfile - a richer format with supporting lock files.
Pipenv doesn't automatically activate the venv on entry into a shell. But a shell plugin named pipenv-activate supports this. It does what you use direnv for in this case, without an envrc file in the source.
One major difference of pipenv from vanilla venv is that pipenv creates the venv in a common location outside the project (like poetry does). But this shouldn't be a big problem, since you wouldn't commit the venv into VCS anyway.
BerislavLopac
Pipenv is certainly not "officially recommended", and it should be avoided at all costs: https://chriswarrick.com/blog/2018/07/17/pipenv-promises-a-l...
syhol
I'm using it to unify my teams toolchain without resorting to nix or running everything in docker.
I still use docker to run services and I still like the idea of nix, but the DX of mise is too good. Tasks are really nice too, all my repo scripts now have completions.
aiono
Did you try https://devenv.sh/? It uses Nix under the hood but with an improved DX experience. I haven't used it myself personally since I find Nix good enough but I am curious if you would still choose mise over devenv.
yawaramin
We are starting to adopt devenv in our team. Overall it's really good--we have control over our toolchain, environment, and the processes that we start. There are some lingering papercuts though, like they haven't yet released a version where they allow specifying the Go toolchain version, and they seem to periodically re-download the Nix package archive. But I think they are improving fairly quickly.
Ultimately, we might still end up moving to straight Nix flakes, just not sure yet.
pxc
> they haven't yet released a version where they allow specifying the Go toolchain version
Devenv's maintainers are friendly and responsive when it comes to contributions from downstream, and like 90% of the devenv repo is plain ol' Nix code written in idioms that are common in the community.
I mention it because my team has hit some papercuts as well, but I've been really happy with how easy it's proven to address them. :)
konradb
I'd be interested in anybody who has tried https://devenv.sh/ and https://www.jetify.com/devbox and chosen one over the other. Tried devbox which has been good, but not devenv.
syhol
I briefly tried devenv and I find it much easier to use than raw nix, but I also had issues with my nix install on macos (using both the official and the DS installer). It worked well on my linux machine.
Today though mise has so many other great features, I would still choose it over devenv or devbox.
mootoday
I've used Devbox for two years for my projects and any work I've done for my clients.
I'm curious what some of the mise features are you like.
BiteCode_dev
My experience with such tools is that when you do everything, you don't do anything right.
The chances that it doesn't leak greatly the underlying abstraction and creates troubles to figure it out when it will invariably fail is zero.
Because most people barely know in depth the packaging challenges for one ecosystem. In Python there are maybe a dozen in the world that have a good hang of __all__ of it.
And the devs of this tool would need to know so many.
Of course they don't, they wrap existing tools, which implies exactly what I said above.
jdxcode
I wonder if you misunderstood what mise is based on your mention of "packaging challenges". mise deals with language runtimes and dev tools—it doesn't manage dependencies or package anything.
I often hear suspicion about mise for this reason from people that haven't used it. I suppose it's not surprising. That said, I have spent over a decade in the developer productivity space as well as hundreds if not thousands of hours working on mise in the last 2 years—if there is someone that can build this I'm probably the right guy for the job.
Particularly with dev tools, it's long been the case that mise has solved this problem. Improvements are continuing to be made with things like improving supply chain security and ergonomics with python—though it's not like the python community itself has its DX figured out.
Of course I'm still fixing bugs pretty regularly and that probably won't ever change but there are hundreds of thousands of developers out there using mise (kind of a guess, but I'm pretty sure) and it's working great for them. It's in the top #100 tools in homebrew now: https://formulae.brew.sh/analytics/install-on-request/30d/
This definitely isn't some scrappy project—I've devoted much of my life to this problem and I think all evidence points it it being a resounding success.
nlh
I have to say, I've been reading your replies here (and your big reply in the just thread) and I'm super super impressed with your dedication to this project. I can tell just in how you write, the volume of responses in this thread, and your tone that this is a real passion project and you're deeply serious about this. I love seeing this. Thanks for your dedication!
(And now I'm off to go try mise....)
jdxcode
I really appreciate that. It's definitely something I get a ton of satisfaction about of building. Drop by our discord and let me know how it goes!
BiteCode_dev
In all scripting language, packaging problems mostly stem from bootstrapping.
Nvm shims break, python path confusion, gem installed on the wrong ruby interpretters, etc.
Maybe you managed the impossible.
But in 20 years of python I've seen only one tool doing bootstrapping in the right direction, all the other ones have failed.
So I'm suspicious of something that does multiple languages.
In the case of mise, it delegates this complexity to the user. E.g: for python, you have to know the config choices, and choose the right backend like asdf, pyenv, or indygreg.
Then you better understand the consequences of that choice.
To me, that's alreay a leak of the abstraction.
arcanemachiner
> But in 20 years of python I've seen only one tool doing bootstrapping in the right direction, all the other ones have failed.
Which tool is that?
rsyring
I think mise gets a lot right. I use it for environment variables, Python virtualenv creation and activation, and task scripts.
I've been a software developer for over twenty years and am usually reluctant to use new tools. But mise has been a fantastic addition to my dev workflow.
stavros
I have two problems with Mise: There isn't a page with the most common commands I might want to run, and whenever I try it, some Python imports mysteriously fail. Then I disable it, and everything is fine again.
I might be motivated to persevere if I only had one of the above problems, but with both of them together, it's too much of a hassle.
jdxcode
there's a list with common commands you might want to run: https://mise.jdx.dev/walkthrough.html
if you post an issue/discussion about the python thing I'd love to investigate it a bit
undefined
rsyring
If you want to post a discussion on the mise GH repo, I'd be happy to help. Feel free to @ me in that discussion so I don't miss it.
cstrahan
> Because most people barely know in depth the packaging challenges for one ecosystem.
I think you’re greatly overstating the problem, at least insofar as it relates to this tool.
For example, Python has its prefix (where packages are installed) baked into its installation. pip, ux, poetry — whatever — are going to install python packages there.
This tool is unconcerned with package installation — it is only concerned with getting the interpreters installed and managing which one is on your $PATH.
There’s literally nothing to leak.
And regarding “wraping existing tools” as proof of some shortcoming in mise (and/or similar) — if they reinvented the wheel, that’s where things could leak. And separation of concerns is a good thing.
BiteCode_dev
Bootstrapping python incorrectly is the main source of packaging problem.
There is a lot to leak. For exemple, if you install a non wheel compiled extension, you'll need the headers, but some python distro don't provide it.
Then of course, on windows, is your python registered with the py launcher? How does it interact with existing anaconda installations ? On linux on existing system installation ? Is the shim (or path update for mise) affecting /bin/env ? How that works with .pyw association ?
The. what does it implies on the venv creation and activation ? And on using -m ? And .pth files ? user-sites ?
All those questions are linked to bootstrapping.
What happens then is pip install fail or import break, but the user have no idea it's related to his bad python setup because most people don't know how it works.
And now bootstrapping has broken packaging.
This is where most "python packaging sucks" things are born: from unkowingly botching the bootstrapping.
And the vast majority of tools to do it suck. E.g: Shims are all kind of broken (pyenv and rye come to mind).
To suceed, mise would have to know all that, pick the right tool, make a perfect abstraction, create fantastic error reporting, and test all those cases on ci on all platforms.
It's possible, but I know only one project that does this almost correctly. And even this one has a long way to go.
Saying "there is literally nothing to leak" is actually perfectly making my point most people don't know the topic deeply enough to know what they get into.
Then of courses there are all the modes of failure. This article has a good bit about that:
https://www.bitecode.dev/p/why-not-tell-people-to-simply-use
It's cover more than mise's scope, but the idea is there.
HelloNurse
I'm trying to use rye on Windows, but it doesn't want to use the normal installed Python version, only the versions it downloads itself, and it cannot update them easily because it pins an old one to run itself.
So far I've wasted more time than I saved.
shepherdjerred
It might be useful for you to try the tool before complaining about it
I’ve used mise for years. It works perfectly well. I use it for Go, Node, Deno, Java, Python, Ruby, and Rust.
PufPufPuf
Your experience with "such tools" covers experience with Mise, or are you just making assumptions?
My experience with Mise is that it's a great tool.
coldtea
>My experience with such tools is that when you do everything, you don't do anything right.
Does it matter? Even dedicated tools don't do everything right.
As long as it does the things one wants to do good enough, and offers a cohesive interface to them...
hinkley
Example: I tried to convince our deployment system to deploy patch releases to simplify our hotfix solution. The code was in Node and the deployment tool in Python. I had to thread the needle to come up with a semver pattern that was legal in both Python and NodeJS. Not impossible but annoying. (Then discovered our deployment tool wasn’t using the semver parser in Python and it still didn’t work. Goddamnit.)
BeetleB
> My experience with such tools is that when you do everything, you don't do anything right.
As a long time Emacs user, I agree :-)
0xbadcafebee
I'm not "a developer" so I never got the use case of tools like these. Instead I just use the stuff they mention (asdf, make).
I use Asdf to manage versions of all programs in a monorepo. Works great (well, actually asdf's UX is terrible, but it works reliably, and the plugin design is great).
For development, I don't ever load environment variables into my current shell session. I run a script or Makefile which loads any necessary variables, does a thing, and then exits. It would be a nightmare to have to constantly check if my current shell session had X variable in it.
I use Make for repeatable small commands that will vary per directory, or for simple parallelizing or ordered execution of commands. I have a big one that handles Helm installs, and a few more for Terraform, Packer, asdf, etc. I also use them for deployments in hierarchical environment directories, where environment variables are loaded from parent directories. I love that Make has all the features it has, because I always find myself eventually reaching for something you don't find in "just a task runner", and it makes my life easier.
I use shell scripts when I need to make a composeable tool that'll be slightly longer or more complicated than a Make target should be. I have saved so much time and effort writing these tools in shell rather than Python or something, where there is inevitably way more bugs and dependencies. The only time I have needed to use something more complex than shell is when I have a lot of APIs to deal with that also deal in JSON; if it's a lot of complexity it's better than curl/jq, but if it's only one small task, curl/jq is better.
The end result works great. The whole environment just needs asdf installed (from Homebrew, for example). With stock Make and the stock Bash v3, I can manage everything automatically, everything's version-pinned and automated, all variables get loaded at runtime as needed, and the whole thing can be grokked by just reading some simple Makefiles.
The only thing I want to fix now is to get rid of the superfluous Makefiles from directories (they're all symlinked back to one Makefile). It's a pain to re-symlink them all when I change directory structure. Probably should just write a script for it...
PufPufPuf
I use Mise as a drop-in replacement for asdf. It's fully backwards compatible with .tool-versions and other config files, and unlike asdf it uses a PATH-based approach instead of shims.
goku12
I'm alright with the loading time for shims, because I find the constantly changing path variable a bit jarring. Not a deal breaker, I must admit. But when I try to use shims instead of the shell plugin, I lose the environment manager. I wonder if there is a way to activate just the environment manager.
syhol
All the features are opt-in. I started using mise because I wanted something like asdf only without the bad UX, and mise can use asdf plugins.
For env vars, you don't need to load them into your shell if you don't want to. When you run a task, mise will make sure the env vars in your config are set, so thats not something you need to worry about.
I still use shell scripts like you describe, mise just supercharges them a bit. When I need to make sure my teammates have the tools in that script (like jq) installed, mise just ensure they are installed before running the command, as long as you declare them in your tools list.
If your setup works for you thats great.
jdxcode
if you use asdf you can drop mise right in and it'll work the same but faster and with better supply-chain security. people have been doing this for almost 2 years and mise fits that use-case perfectly.
You don't have to touch the env vars and tasks stuff.
hv42
I think you should give `mise` a chance. I believe it can help improve your workflow.
It's better at managing tools than `asdf`, very close to `direnv` and superior to `make` as a task runner (more verbose but much easier to understand). One of the advantages is that `mise` tasks can be standalone files (you can even write file tasks in python if you prefer, see https://mise.jdx.dev/tasks/file-tasks.html)
svilen_dobrev
i have similar tree-containing-symlinks-to-one-thing - and i do it by symlinking each x to ../x ; and only the root x (of any tree) is a real thing (or missing, if it lives on some other device). Thus the structure is still tar/archievable.
Of course you can do things like these too:
$ MAKEFLAGS="-f /that/root/makefile" make
or (rude)
$ alias make="make -f /that/rooty/makefile"
but beware that adding another -f somemakefile will load both specified.
Apart of it, my biggest grievance with make is that it cannot handle spaces in names. By design.
RobT7k
I'd really like a better idea on Windows support for mise. Especially for development using WSL. It seems like it probably works there, but the docs are pretty slim.
> Note that Windows support is very minimal for now.
DrBenCarson
Just using mise as a drop-in asdf replacement has been delightful
Same functionality but much snappier with better ux
mootoday
I read the project's Readme and all I'm left with is "why?".
I use Devbox[1] and get access to the entire Nix ecosystem, done.
goku12
There are multiple tools in this space - even devbox has a direct competitor. With mise, I'm not expecting an isolated environment, but rather a meta package manager. I can install many tools directly into my user shell. If I wanted that with nix, I would be using a nix user install rather than devbox.
You just choose what you like most. And mise seems to have a large fanbase.
Zizizizz
Mise just works and takes maybe 1-2 minutes to explain and have a tool running on a team members machine in my experience. I couldn't get into nix, too complicated for me and I've yet to find a resource that makes it click for me. After that I would feel comfortable encouraging the rest of the team to use it but as mise is so easy and even more popular, I will probably just stay using this. I will look into devbox though, thank you for the recommendation!
mootoday
I hear you, Nix has been nothing but a waste of time for me every time I tried to do anything with it.
Devbox abstracts it and the only time I had to do a nix-specific thing was when I needed a flake to install a CLI from a GitHub release.
dmarinus
Lately I was thinking "what's the best way to integrate/use a task runner like mise in a github actions workflow".
Looking at the workflow files in the mise repository it seems like they gave up and just put in a few run: mise steps (having to rewrite / unable to use dependencies etc).
I think it would be better if you could generate the workflow files but I haven't found such a project yet.
jdxcode
there is a `mise generate github-action` command which uses https://github.com/jdx/mise-action
not sure I understand what you mean by "mise steps (having to rewrite / unable to use dependencies etc)."
ducdetronquito
It's a simple tool that makes my life easier for more than a year: thanks to the creator and contributors :)
lijok
The name is absolutely perfect.
Alifatisk
I'm glad people doing frontend are working towards creating a whole toolchain that does everything, like biomejs.dev.
Get the top HN stories in your inbox every day.
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.