back
1 comments
I feel like they're just hitting the limits of a bash+shims based approach. I understand why they've done it, but in the end an implementation in a compiled language will beat that approach most of the time. There are issues since a shell hook will only work as long as you're, well, using a (supported) shell.

However, it's surprising to hear that they've been focusing on UX. The fact that you have to manually install a plugin, then install a version, and then finally set it, without the tool suggesting any of those steps to you when you forgot one, really makes the tool annoying to use when switching versions a lot.

I don’t agree.

As a proof of concept I wrote a Fish native version of the function that figures out what local version of a tool to use I do actually use it to show the currently selected version in my shell prompt. The asdf version was unusable in a shell prompt.

It goes through the parent directory structure up until the top level root directory and finds the first .tool-versions file and parses out the version of a specific tool.

The asdf native shim takes ~100 ms in Bash (no idea if it can be optimized, but I assume so). My Fish version takes ~1 ms.

I'm not familiar with the performance characteristics of fish, so I can't really speak to that. I only remember that the developers of asdf themselves had problems with resolver/shim performance and even temporarily implemented only that specific part as a go executable, and projects like asdf-direnv also try to work around the problem.