I would say the biggest barrier is developers not wanting to jump on yet another "this language will solve all your problems, trust me" train.
My experience in my 15 years in software, is that good developers solve problems, not languages or tools.
... a programming language designer should be responsible for the mistakes that are made by the programmers using the language.
[...]
It's very easy to persuade the customers of your language that everything that goes wrong is their fault and not yours. I rejected that...
If anyone is unfamiliar with Tony Hoare he's the creator of quicksort, Hoare Logic, CSP, worked on Algol, created null, holds a turing award, and much more.
At 15 years I thought the same. At 25 years I have come to really appreciate some tools ability to help.
There are a lot of tools that claim to help but don't. Beware of tools that try to manage complexity - what you probably need is to reduce complexity. I'm looking at Eclipse and Matlab in particular, and anything similar (think enterprise software).
Git - awesome. Using it on 1-man projects too.
Sanitizers for C++ I've seen these identify bugs that hadn't manifested visibly yet.
Rust - well I want to write more because it doesnt require additional tooling to write correct code. Remember reducing complexity.
>> At 25 years I have come to really appreciate some tools ability to help.
I've come to find there is a bidirectional connection between good developers and their tools. Good devs recognize and gravitate towards systems that help them thrive, and away from painful ones. Good tools draw in good devs, and the community gets stronger as a result.
IMHO, One hallmark of less-than-stellar devs is a tendency to stick with tools they are familiar with, because "it works." Great devs could get by with a magnetized needle and a steady hand, but they know there is better out there.
Never underestimate what a team of overly enthusiastic junior engineers are capable of :-)
Meanwhile the junior-intermediate devs spend most of their working hours writing code, so they are extremely sensitive to the 5-10% productivity bump that could be gotten by using {nicer language, better build system, static analysis tooling/sanitizers, ${TOOLING_IMPROVEMENT}.
I'm talking real advances in productivity. Imagine working on a C++98 codebase today in 2021 because you're working on a very large industrial product that's been around for decades. It can be demoralizing, like having to write COBOL or FORTRAN.
Package managers, which ones?
Perl was the very first, almost every language has their own, and even the growing C++ ones are able to use binary libraries on their package managers.
Python's Poetry comes to mind.
In terms of influences, here's an OCaml attempt to replicate cargo (I wish them well): https://github.com/OCamlPro/drom
Klabnik also mentioned Python's poetry below. Yarn as well, since Yehuda Katz was involved.
Note: I seem to recall you're an Ada dev, so I should mention that as far as build tools go, I've always really appreciated gprbuild, which is far superior to other build tools of its vintage. If it had a built-in package manager like cargo, it could compete with cargo.
I like Ada, but no not an Ada dev, rather JVM/.NET/C++, I rather go polyglot.
And in this regard, while cargo is nice, I don't see how it is better than Maven (I don't suffer XML allergy), NuGET, vcpkg/conan, specially because it only does source packages with npm like levels of dependencies.
Anyway, yeah, Maven is very good and competes with cargo, as well. I agree.
Nuget? Absolutely not, based on my previously undefined rubric. Unlike Maven and cargo, it's just a package manager unless it's recently been expanded (I'm not much of a Windows guy, so not sure). With some pretty crappy defaults as of a year or two ago. No idea about vcpkg or conan.
(I probably should have specified that I'm comparing among package manager that include build tools - or vice versa).
Edit: I suspect cargo will get around to binary packages at some point, as soon as that limitation is resolved in rustc using something like TUF. cargo has not been around nearly as long as Maven.
And for the record, despite my love for functional programming, I also have a strong appreciation for Java (not as much as Ada, but it's a great language when used by competent devs).