I think the scale of the problem has a lot to do with the platform and ecosystem you're working in. My experience with, for example, Javascript and Ruby (npm and gem) is very much in line with the painful situation you describe. But that's in stark contrast to my experience with Java and .Net where the problem tends to be much less of an actual problem. That's very anecdotal evidence, for sure, but strong evidence in my world and I doubt I'm unique.
Like everything else, using some kind of cloud-based dev environment comes with tradeoffs (significant ones, in my experience), some of which you've touched on. It had better bring great benefits to justify those tradeoffs.
I was going to say much the same: every time I've had to work with a Ruby project, it has just randomly broken at some point, and often required arcane environment tweaking to fix it; I've worked with Clojure for almost 15 years on the JVM and I've _never_ had a random breakage like that.
I've advocated for standardized development environments for years, there is no doubt this is the most efficient way to develop software. Unfortunately still to this day, it takes a large effort to educate technical leadership of the benefits. Unless a company's CTO is open-minded enough, adoption will fail.
I have had very good results solving this problem with Nix, taking new developer onboarding from 2 weeks down to 1 hour. Would be minutes if we invested in a binary cache. The same nix flake can then be used in a cloud dev env, in CI, even in production.
I see Nix advocates popping up all over the place, struggling to get new versions of tools working with Nix's view of the world -- so my exposure to Nix through that has been overall negative, as it just seems to replace one type of dev env tinkering with another.
Replacing one type of dev env tinkering with another is not an inaccurate description. The benefit is the Nix type is reproducible, cross-platform and source controlled, which solves the problem described in the article. Tinkering for everyone's benefit is better than tinkering with your own and everybody else has just as much tinkering to do.
Plain Nix worked well in my company's use case but there are actually many tools that can solve this problem with various tradeoffs, like mise and asdf, as well as Nix wrappers like devenv.sh, flox and devbox. They are all worthy of being in the toolbox, the best one depends on the needs of the environment.
Oh, I totally understand what the claimed benefits are -- and I know that many Nix users are very happy with it. I suspect if I worked across a wide variety of tech and tooling, I might benefit from the ability to have each project "magically" have the tech/tooling environment required, in a predictable, repeatable manner.
But I pretty much exclusively work on the JVM: I have a variety of JDKs installed for multi-version testing, but all my dependencies are managed by the "build tool" rather than any package/environment tool.
In addition to the Nix and Devcontainers mentioned in other comments, I want to highlight Mise.
Mise manages tool versions in much the same way as npm and gem manage libraries. A `.tool-versions` file in the root of the repo indicates the exact versions of every tool, e.g. ruby or node java, giving a consistently-reproducible build on all machines.
Taking Java as an example here, a clean machine isn't going to have a JDK installed, or a "build" tool (e.g., Maven), so just `git clone` and running a (shell) script isn't going to be enough -- unless that script installs both of those for you if needed, on every O/S (and your script has to run on Windows, macOS, and Linux too).
If your "clean machine" meets the pre-reqs for a source repo -- an appropriate JDK and `mvn`, for example -- then, yes, I agree with you.
(also, some "clean machines" aren't even going to have git I suspect?)
I'm willing to grant git to a clean machine, but not JDK and Maven. Getting the "right" version of JDK installed and setting JAVA_HOME is exactly the kind of bullshit we shouldn't be demanding of the person that has just cloned the repo for the first time.
For a maven project, you only need the JDK installed (any version equal to or later than the one required by the project, they don't really ever break backwards compatibility). If the project was set up to use the maven wrapper, you don't even need maven itself as a prereq.
Gradle can do even better. It has gradlew, the wrapper concept that maven later copied, and can automatically download and use a JDK via its JVM toolchains feature.
I haven't manually set or used JAVA_HOME in years, possibly more than a decade. That's outdated old-school stuff.
I think the scale of the problem has a lot to do with the platform and ecosystem you're working in. My experience with, for example, Javascript and Ruby (npm and gem) is very much in line with the painful situation you describe. But that's in stark contrast to my experience with Java and .Net where the problem tends to be much less of an actual problem. That's very anecdotal evidence, for sure, but strong evidence in my world and I doubt I'm unique.
Like everything else, using some kind of cloud-based dev environment comes with tradeoffs (significant ones, in my experience), some of which you've touched on. It had better bring great benefits to justify those tradeoffs.
I was going to say much the same: every time I've had to work with a Ruby project, it has just randomly broken at some point, and often required arcane environment tweaking to fix it; I've worked with Clojure for almost 15 years on the JVM and I've _never_ had a random breakage like that.
Managed VMs like .NET and the JVM tend to make the local development experience super easy, as long as you stay on the paved roads.
For some transparency, Kent is an investor in GitPod (https://www.gitpod.io/blog/future-of-software-cdes).
Cloud-only solutions are, IMHO, a half-baked solution. I explored that in detail in 2022 (https://www.mootoday.com/blog/dev-environments-in-the-cloud-are-a-half-baked-solution).
I've advocated for standardized development environments for years, there is no doubt this is the most efficient way to develop software. Unfortunately still to this day, it takes a large effort to educate technical leadership of the benefits. Unless a company's CTO is open-minded enough, adoption will fail.
What about development containers? Dev containers is currently supported by at least vscode and jet brains IDEs.
I have had very good results solving this problem with Nix, taking new developer onboarding from 2 weeks down to 1 hour. Would be minutes if we invested in a binary cache. The same nix flake can then be used in a cloud dev env, in CI, even in production.
I see Nix advocates popping up all over the place, struggling to get new versions of tools working with Nix's view of the world -- so my exposure to Nix through that has been overall negative, as it just seems to replace one type of dev env tinkering with another.
Replacing one type of dev env tinkering with another is not an inaccurate description. The benefit is the Nix type is reproducible, cross-platform and source controlled, which solves the problem described in the article. Tinkering for everyone's benefit is better than tinkering with your own and everybody else has just as much tinkering to do.
Plain Nix worked well in my company's use case but there are actually many tools that can solve this problem with various tradeoffs, like mise and asdf, as well as Nix wrappers like devenv.sh, flox and devbox. They are all worthy of being in the toolbox, the best one depends on the needs of the environment.
Oh, I totally understand what the claimed benefits are -- and I know that many Nix users are very happy with it. I suspect if I worked across a wide variety of tech and tooling, I might benefit from the ability to have each project "magically" have the tech/tooling environment required, in a predictable, repeatable manner.
But I pretty much exclusively work on the JVM: I have a variety of JDKs installed for multi-version testing, but all my dependencies are managed by the "build tool" rather than any package/environment tool.
Devs working exclusively in Go also tend to find this gymnastics amusing.
This is why we have such a wide variety of tech -- so we can each find other developers' gymnastics amusing :)
Even in Kent‘s native Environment of VisualWorks Smalltalk; there is +10% churn to keep it running while in a bimonthly release cadence
In addition to the Nix and Devcontainers mentioned in other comments, I want to highlight Mise.
Mise manages tool versions in much the same way as npm and gem manage libraries. A `.tool-versions` file in the root of the repo indicates the exact versions of every tool, e.g. ruby or node java, giving a consistently-reproducible build on all machines.
For every source repo in the world I should be able to clone it onto a clean machine, run the build-and-test script at the root, and it just works.
Every time I tell developers this they nod their heads in agreement, but as an industry we're really far from making it happen. Let's do better!
Taking Java as an example here, a clean machine isn't going to have a JDK installed, or a "build" tool (e.g., Maven), so just `git clone` and running a (shell) script isn't going to be enough -- unless that script installs both of those for you if needed, on every O/S (and your script has to run on Windows, macOS, and Linux too).
If your "clean machine" meets the pre-reqs for a source repo -- an appropriate JDK and `mvn`, for example -- then, yes, I agree with you.
(also, some "clean machines" aren't even going to have git I suspect?)
I'm willing to grant git to a clean machine, but not JDK and Maven. Getting the "right" version of JDK installed and setting JAVA_HOME is exactly the kind of bullshit we shouldn't be demanding of the person that has just cloned the repo for the first time.
We're getting kinda off-topic, but...
For a maven project, you only need the JDK installed (any version equal to or later than the one required by the project, they don't really ever break backwards compatibility). If the project was set up to use the maven wrapper, you don't even need maven itself as a prereq.
Gradle can do even better. It has gradlew, the wrapper concept that maven later copied, and can automatically download and use a JDK via its JVM toolchains feature.
I haven't manually set or used JAVA_HOME in years, possibly more than a decade. That's outdated old-school stuff.
SDKMan helps, sometimes a lot depending on which platform you're working in.