[bassdropvroom]

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.

[e12e]

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]

> 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]

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

[mega-tux]

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

[TeddyDD]

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]

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]

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

[TeddyDD]

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

[renewiltord]

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]

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