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.
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.
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'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)."
28 comments
[ 7.0 ms ] story [ 204 ms ] threadSo 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.
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.
Have you seen a difference yourself, and if so, could it have been from the overhead of loading gems instead?
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-...
1 - https://en.wikipedia.org/wiki/David_Frum
https://en.wikipedia.org/wiki/John_Frum
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.
Esbuild comes to mind ?
I wonder if there's a Ruby bundler written in another lang?
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