Certainly looks nice, but all of these different version managers are just not necessary. When you have something like asdf written in what feels like 1 line of bash (obvious exaggeration) everything else feels redundant. I've been able to remove gvm (golang), tfenv (terraform), and several others that I can't think of right now.
I love asdf, but one of the reasons it's so great are the other, dedicated, version managers (eg: ruby-build for asdf-ruby, rustup/cargo for asdf-rust etc).
So asdf absolutely needs other version managers. Not sure how a ruby version manager in rust will help - the only thing that's slow with asdf-ruby is building any given version of ruby... And that can't really be significantly improved on? At least not for legacy versions.
> Not sure how a ruby version manager in rust will help - the only thing that's slow with asdf-ruby is building any given version of ruby
Worth noting that there are benefits to doing a CLI in Rust other than raw processing speed:
1) Type system
2) Compared with C/C++:
2a) Safety
2b) Trivial cross-platform builds with no runtime dependencies
2c) Stellar package ecosystem to build on, including powerful CL arguments handling
3) Compared with interpreted languages
3a) No runtime dependencies
3b) Fast cold-start because it's a native binary
Of course none of these makes it the automatic winner, and several don't really apply when compared to shell scripts. But the type safety does, and another big one that comes to mind is trivial Windows support, which from a quick glance asdf doesn't seem to have.
asdf is nice except is uses shims. They are pretty slow. If you offten run script as part of your prompt for example, it gets noticable pretty quickly.
At least for terraform, I find using an env an anti-pattern. The software moves too fast and you get stuck if you can't just stay up to date. I have done both the env route and the stay-up-to-date route on non-trivial infra (~1MM/mo) and the latter is far superior. It's not too bad when you just need to keep moving up and it's a small task.
If I'm reading their benchmarks right, rbenv takes (mean) 239628.1ms and Frum takes 232944.6ms to install ruby, for a 2.8% speedup. It looks like a pretty new project, though, so that may just be the starting point.
That's the way I read it, although I don't understand why they're focusing on installation. That seems like choosing a car based on how long it takes to change the oil.
I'd be more interested in a benchmark of how much slower it is than having the right version of Ruby directly in your path, or versus rbenv shims.
HI. I'm an owner of this repository. You're right. And the reason why I chose the name frum instead of frm is that frm is hard to call and I don't feel attached to it.
I've written a guide to Install Ruby with Frum[0]. I think it's a great alternative to rbenv, RVM, chruby, or asdf.
From the article: "There are no shims (unlike Asdf or Rbenv) and it doesn’t override the cd command (unlike RVM). it includes a built-in Ruby installer command so there’s no extra program needed to install Ruby (unlike Chruby). The installer is fast and Frum requires no dependencies (it’s an all-in-one Rust executable you can install with Homebrew)."
