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.

Is it related to common lisp asdf or is it pure lexical collision ?

not related. There was an old issue created for this but the author will not change the name

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.

This surprises me. The shim should only introduce the latency of a single disk read, right?

Have you seen a difference yourself, and if so, could it have been from the overhead of loading gems instead?

I've seen this difference myself and done some profiling on it in the past with asdf.

I also know that Sam Saffron has mentioned the shim latency a bit before as well with other tools.

> We stopped benching on rbenv based systems, everyone moved to chruby or rvm cause the shims rbenv adds introduce significant delays on boot.

https://discuss.rubyonrails.org/t/why-is-rails-boot-so-slow-...

Take a look at this issue: https://github.com/asdf-vm/asdf/issues/290

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.

absolutely this, asdf saw the true problem with version management and provided an elegant solution.

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.

I just use Nix for this. The nice thing with it is it's uniform and you can manage versions for any language.

I am working on building VirtualBox appliances based off of NixOS. Nix makes me feel dumb.

It makes you feel dumb until you keep plugging away and suddenly you can use it and you're not sure why it's all making sense

I love everything about what Nix is achieving, and have a lot of problems with how it achieves it.

I'm curious about the name. Frum is Yiddish for 'religious'.

Betting it's because it's a Fast RUby version Manager?

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.

It almost definitely has nothing to do with David Frum[1], but that's where my own odd mind went first.

1 - https://en.wikipedia.org/wiki/David_Frum

Does it have anything to do with John Frum?

https://en.wikipedia.org/wiki/John_Frum

I'd be intrigued to see a benchmark against chruby/ruby-install. Doing the shell config isn't where I'd assume the slow bit is.

I'd also like to see a benchmark against chruby/ruby-install. I believe many developers moved from rbenv to chruby for speed.

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)."

[0] https://mac.install.guide/ruby/14.html

Odd to see pm for lang-a written in lang-b.

Esbuild comes to mind ?

Volta as well https://volta.sh/ – A Node version manager written in Rust.

I wonder if there's a Ruby bundler written in another lang?

Talk about optimizing the wrong loop.