People may learn from material that uses C for illustration purposes, but that won’t prompt them to write their own C. And don’t even mention ecosystem support in C/C++ where developers are notorious for reimplementing everything on their own because there is no package manager.
Conversely, "why does my hand-written CSV parser only support one of the 423 known variants of CSV, and it isn't the one our customer sent us yesterday?"
You kind of have a point behind dependency hell, but the flip side is that one needn't become an expert on universal CSV parsing just to have a prayer of opening them successfully.
You are greatly exaggerating the numbers, and Rust and its ecosystem are known for being stable. Are you saying everyone should write their own csv parser? Also it’s highly likely that an existing CSV library would be optimized, unlike whatever you wrote ad-hoc, so your performance argument doesn’t hold.
I'm saying package managers automate dependency hell and software is and will be less stable & more bloated as a consequence. And one should know how to write a csv parser and yes, even consider writing one if there are obvious custom restraints and it's an important part of one's project.
(and yes, numbers were exaggerated; I picked something trivial like a csv parser pulling in 89 packages for effect; the underlying principle sadly holds true)
Anyone can read a file, split it by newline and split it by comma, but what if values contain newlines or commas? How do you unescape? What about other edge cases? In Rust an existing library would handle all that, and you would also get structure mapping, type coercion, validation etc for free.
The number of dependencies does not indicate how bloated your app is. Package managers actually reduce bloat because your dependencies can have shared dependencies. The reason C programs may seem lightweight is because their number of dependencies is low, but each dependency is actually super fat, and they tend to link dynamically.
In the context of Rust it is not about "bloat" indeed. The compiler includes only used bits and nothing more. However, there are other problems, like the software supply chain security. More dependencies you have, more projects you have to track. Was there a vulnerability that affects me? Is project unmaintained and some ill factor took it over?
In C this was actually a less problem since you had to copy-paste the shared code into your program and at some level you were manually reviewing it all the time.
Also in Rust people tend to write very small libraries and that increases the number of dependencies. However, many still not follow SemVer et. al and packages tend to be unstable too. On top of additional security issues. They maybe be useful for a short time but in many cases you might need to think the lifetime of your application up to 10 years.
> However, there are other problems, like the software supply chain security.
It's not a problem with Rust specifically though. It's not unique to Rust.
> Also in Rust people tend to write very small libraries and that increases the number of dependencies. However, many still not follow SemVer et. al and packages tend to be unstable too.
Don't use random unpopular crates maintained by unknown people without reviewing the code.
