Broadly I agree but I think the cargo tooling is one of the strengths of rust. The dependency downloading probably had to exist while rust was establishing itself and maturing as an ecosystem.
It’s a fair question. Personally for me crates.io seems to exercise good taste in what it adds and unlike npm doesn’t (yet) have a long history of exploits. Also npm seems more prone to dependency explosion (leftpad,is even etc). Also I feel as though I have a fighting chance understanding the rust source should I need to delve into it.
I think you are right, but IMO the reason is just a difference in numbers. If crate.io ever gets as much users as npm the problems will become exactly the same.
As soon as there is a situation where one dependency can decide tomorrow to pull in another one everybody is screwed. You might be comfortable with understanding the code, but if you don’t have the time to fix it you are screwed either way. The customer always says “it worked yesterday, what do you mean you need to fix something? Work on this new feature instead”. One year of this any you cannot manage your dependencies anymore and you have hundreds, welcome to npm.
Broadly I agree but I think the cargo tooling is one of the strengths of rust. The dependency downloading probably had to exist while rust was establishing itself and maturing as an ecosystem.
FWIW I wouldn’t touch npm with a barge pole.
What are the differences between cargo and npm that make you approve of the former and disapprove the latter?
It’s a fair question. Personally for me crates.io seems to exercise good taste in what it adds and unlike npm doesn’t (yet) have a long history of exploits. Also npm seems more prone to dependency explosion (leftpad,is even etc). Also I feel as though I have a fighting chance understanding the rust source should I need to delve into it.
I think you are right, but IMO the reason is just a difference in numbers. If crate.io ever gets as much users as npm the problems will become exactly the same.
As soon as there is a situation where one dependency can decide tomorrow to pull in another one everybody is screwed. You might be comfortable with understanding the code, but if you don’t have the time to fix it you are screwed either way. The customer always says “it worked yesterday, what do you mean you need to fix something? Work on this new feature instead”. One year of this any you cannot manage your dependencies anymore and you have hundreds, welcome to npm.