3 ms·

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

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.

throwbacktictac 5y ago
absolutely this, asdf saw the true problem with version management and provided an elegant solution.
e12e 5y ago
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 5y ago
  > 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.
agumonkey 5y ago
Is it related to common lisp asdf or is it pure lexical collision ?
- mega-tux 5y ago
  not related. There was an old issue created for this but the author will not change the name
TeddyDD 5y ago
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 5y ago
  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?
  - philipbjorge 5y ago
    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-on-macos/74021 https://discuss.rubyonrails.org/t/why-is-rails-boot-so-slow-...
  - TeddyDD 5y ago
    Take a look at this issue: https://github.com/asdf-vm/asdf/issues/290 https://github.com/asdf-vm/asdf/issues/290
renewiltord 5y ago
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 5y ago

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

e12e 5y ago

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 5y ago
> 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.

agumonkey 5y ago

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

mega-tux 5y ago
not related. There was an old issue created for this but the author will not change the name

TeddyDD 5y ago

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 5y ago
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?
- philipbjorge 5y ago
  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-on-macos/74021 https://discuss.rubyonrails.org/t/why-is-rails-boot-so-slow-...
- TeddyDD 5y ago
  Take a look at this issue: https://github.com/asdf-vm/asdf/issues/290 https://github.com/asdf-vm/asdf/issues/290

renewiltord 5y ago

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.