Yeah, I've been around this block many times. I've been in the industry since the mid-90s. The problem comes down to that people have all sorts of different motivations in why and how they use technology, and organizations and projects are difficult ships to steer, and the palette of available choices is not always what we want.
I prefer not to consider other people as ignorant or stupid. They just have different motivations or reasons.
But back to the topic: I do think Cargo should have started from looking at Maven as an engineering foundation rather than NPM. Maven shipped from the start with solutions to many of the problems that Cargo is sick with because they were not considered.
> I prefer not to consider other people as ignorant or stupid. They just have different motivations or reasons.
Oh, I didn't want to imply people are stupid, after all, I (and many other people) made the same error 25 years ago.
But talking about Cargo (the last time I used Java there had been no Maven yet), the packages really need at least some sort of namespaces. But I don't think that (newer) languages without a really "battery" standard library can evade the problems of "too many transitive dependencies".
Yeah I agree in principle. There's lots of people who defend it but I think it is a mistake for the Rust stdlib to be missing a lot of quite basic common stuff (random numbers, sha256, md5 are obvious ones to me for example.) They could even break said lib up (stdlib, stdlib-ext, stdlib-embedded) if necessary. But status quo is just inviting future disaster in my opinion.
And don't get me started on the async story. Yikes. Rust is the language that Tokio ate.
I prefer not to consider other people as ignorant or stupid. They just have different motivations or reasons.
But back to the topic: I do think Cargo should have started from looking at Maven as an engineering foundation rather than NPM. Maven shipped from the start with solutions to many of the problems that Cargo is sick with because they were not considered.