The languages available today are a vast improvement over what was around 15 years ago. This isn't even all that specific to Rust, even many languages which existed back then have improved massively.

Many of which still have some catchup to do regarding Delphi, C++ Builder, Eiffel, Smalltalk and Common Lisp.

I really like Tony Hoare's quote on this topic:

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

http://blog.mattcallanan.net/2010/09/tony-hoare-billion-doll...

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.

>> My experience in my 15 years in software, is that good developers solve problems, not languages or tools.

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.

>>> good developers solve problems, not languages or tools

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

Languages and tools have helped people write better software over the years, no?

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

Never underestimate what a team of overly enthusiastic junior engineers are capable of :-)

There's got to be a middle ground somewhere. I've worked in many places where the tech stack fossilizes because the ROE of learning how to use new, more productive tooling is too much effort for the senior devs compared to their existing responsibilities, many of which are non-technical in nature.

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.

Right, it’s not like Rust has already influenced improvements in other languages and package managers. Definitely a fad

Making other languages take affine times more seriously, I agree.

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.

Among package manager + build tool devs I know, cargo is considered by most I know (maybe 2-3) to be best-of-class.

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.

So good that Google is not using it on Android, nor Fuchsia.

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.

Yeah, I almost changed that "Ada dev" since as a polyglot dev, I figured you'd correct me. What I meant was that you had significant Ada experience (or I'm confusing you w/someone else).

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.

Btw, I'm also a polyglot dev. I've never used rust professionally (unlike say Ada), but I do really appreciate cargo.

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

Rust's package manager has many great features, but it went the other way around. Mozilla hired one of the authors of rubygems and yarn to re-implement their better ideas.

This is true, but so is the grandparent. Poetry, for example, cites Cargo as an inspiration. build2 describes itself as something "that aims to approximate Rust Cargo's convenience for developing and packaging C/C++ projects." I believe Go's "dep" was Cargo inspired as well, though that didn't work out.

Yarn came after cargo was started, I'm fairly sure.

> Package managers, which ones?

Python's Poetry comes to mind.