[HN Gopher] Frum - Fast and modern Ruby version manager written ...
___________________________________________________________________
Frum - Fast and modern Ruby version manager written in Rust
Author : thunderbong
Score : 59 points
Date : 2021-05-21 09:55 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| schwartzworld wrote:
| I'm curious about the name. Frum is Yiddish for 'religious'.
| wcarss wrote:
| 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
| blacksmith_tb wrote:
| Betting it's because it's a Fast RUby version Manager?
| TaKO8Ki wrote:
| 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.
| catlifeonmars wrote:
| Does it have anything to do with John Frum?
|
| https://en.wikipedia.org/wiki/John_Frum
| bassdropvroom wrote:
| 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.
| renewiltord wrote:
| 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.
| throwbacktictac wrote:
| absolutely this, asdf saw the true problem with version
| management and provided an elegant solution.
| TeddyDD wrote:
| 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.
| Conlectus wrote:
| 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?
| TeddyDD wrote:
| Take a look at this issue: https://github.com/asdf-
| vm/asdf/issues/290
| philipbjorge wrote:
| 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-...
| agumonkey wrote:
| Is it related to common lisp asdf or is it pure lexical
| collision ?
| e12e wrote:
| 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.
| brundolf wrote:
| > 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.
| whateveracct wrote:
| I just use Nix for this. The nice thing with it is it's uniform
| and you can manage versions for any language.
| OhSoHumble wrote:
| I am working on building VirtualBox appliances based off of
| NixOS. Nix makes me feel dumb.
| rkangel wrote:
| I love everything about what Nix is achieving, and have a lot
| of problems with how it achieves it.
| whateveracct wrote:
| 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
| regularfry wrote:
| 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.
| kemiller wrote:
| Talk about optimizing the wrong loop.
| agumonkey wrote:
| Odd to see pm for lang-a written in lang-b.
|
| Esbuild comes to mind ?
| hundchenkatze wrote:
| 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?
| fishtoaster wrote:
| 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.
| cjm42 wrote:
| 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.
___________________________________________________________________
(page generated 2021-05-21 23:02 UTC)