[karmakaze]

Out of curiosity, how many dev environments do folks use? Is this for reproducible environments shared by members of a team or company?

For a single user with one development machine, simply having say a time-machine backup could be sufficient. I haven't had challenges for personal projects where details mattered. e.g. a Maven pom.xml, or Go modules/packages was sufficient for my needs.

Historically I'd only cared about automating the spec of production environments. Why would I want/need this?

I now recollect once being contacted out of the blue as being a person who might be able diagnose/solve an issue at a company I'd never worked with. They had two dev machines and only one of them could produce a working program. Their team couldn't figure it out. I gave them a rate and arrived on-site. It was a Visual Basic 6 program, so I just took two half days going through every EXE & DLL related to Windows and VB, eventually finding the difference. Tedious but not rocket science. Is it to avoid these cases?

Edit: We have project onboarding instructions where I work. I suppose it could be useful for making those. I don't make them but could appreciate if they used a standard rather than bespoke scheme.

[jdsalaro]

> Why would I want/need this?

always, golang is overly opinionated regarding where modules and binaries are stored. I don't like that and I've blown my local development environment into pieces because of that (looking at you GRPC, yikes)

But also, imagine that you, like me, need to test Python, Java+Kotlin+Gradle and NodeJS+Angular stuff. Do you really want to install _all that_ natively ? Just for a couple of merge reviews, and even if not, do you _really_ want to install all that natively ? The answer is always, IMHO, a resounding and clear no.

> It was a Visual Basic 6 program, so I just took two half days going through every EXE & DLL related to Windows and VB, eventually finding the difference. Tedious but not rocket science. Is it to avoid these cases?

For example, but also much worst, as mentioned in the OP it's to prevent the very real possibility of crippling your OS's language runtimes and also to stay productive.

[brabel]

IMHO the solution for the problem of devs in the same company having different environments is not Adsf and its competitors like Mise, but things like Nix/Guix and Docker.

At work, because everyone uses Mac, we ended up using Kandji to achieve the same thing: everyone has the same tools and environments, but that is only if you already have to use that due to security audits and stuff like that.

If I had a small company myself I would probably setup everything with Guix as I really like the way it works, more than Nix (though only because I prefer Lisp config files and because Guix doesn't suffer from any polemics like the flake soap opera).

[skydhash]

I just use small VMs. I use Vim as my code editor and just ssh into it. No difference, latency wise. if I was on Linux, I'd use LXC containers.

[neonsunset]

If you had trouble with gRPC and Go combo, you might find the way it is integrated in C# a breath of fresh air.

https://learn.microsoft.com/en-us/aspnet/core/grpc/basics?vi...

[lawik]

I work in about 5-10 versions of Elixir depending on a similar number of specific Erlang versions. At any given time. Also 2-3 NodeJS versions.

It is quite helpful. Also incredibly practical when chevking whether Library X will work on an older version.

I do open source and consulting for clients. I deal with a lot of projects, my own and other's.

[ufmace]

I routinely work in Ruby, Python, Javascript, Java, Go, and Rust. The thing that drives me to use asdf is that without such a tool, every language needs a different version or installation manager and they all work slightly differently. It's a hassle to remember 6 different sets of commands for how to install a new version, check which version is active, switch to a different version, and to remember the slightly different quirks that each language's tool has. With asdf, they all work exactly the same. Granted that with Rust and Go it's usually less necessary to keep older versions around, but you definitely need it for Python and Ruby. Better to have all the languages work the same even if it's a bit more complex than needed for some.

[karmakaze]

Ok, so then it's like a package manager manager. Does it update each package manager's lock files too?

Thanks all for the replies. And sorry if I'm asking basic questions and should just read the asdf readme. On my custom layout I have to type A-S-R-H to get asdf.

[RulerOf]

> Ok, so then it's like a package manager manager.

Still no. asdf manages the versions of the runtimes themselves. E.g. I have a project that uses ruby 2.7.2 and Terraform 1.1.7. If I'm using asdf, I declare this in the .tool-versions file of the project, and then when I navigate to that directory, every invocation of `ruby` or `terraform` will run those exact versions.

Separately, packages (Ruby Gems, Python packages, etc) will also be isolated per-version of each runtime, but that's a side effect rather than the goal with asdf.

[ufmace]

Actually no, it manages the versions of the languages themselves, but doesn't interact with their package managers at all. The .tool-versions file it uses to mark the current version could be thought of as a lock file as well. It replaces (for Ruby) rbenv/rvm, not rubygems. Rustup, not Cargo, etc.