2 ms·
This frankly sounds like a rationalization for an aesthetic preference. It is undeniable that being able to easily build on top of others' hard work is an enorm
by oersted 2y ago
This frankly sounds like a rationalization for an aesthetic preference. It is undeniable that being able to easily build on top of others' hard work is an enormous advantage in any domain.
Duplicate work should only happen if you are confident that your requirements are significantly different, and that you can deliver an implementation as good as a team that has likely focused on the problem for much longer and has acquired a lot more know-how.
It is true that such an attitude might be justifiable for certain security or performance critical applications, you might need end-to-end control. But even in those cases, the argument for trusting yourself by default over focused and experienced library authors is dubious.
Either way, a good dependency manager opens the door for better auditing, analysis and tagging of dependencies, so that such critical requirements can be properly guaranteed, again probably better than you can do yourself.
- palata 2y ago> Duplicate work should only happen if you are confident that [...] You are making a ton of assumptions on the quality of the average library you can depend on: that a whole team worked on it, that it worked on it a long time and that it produced good code. That's really not a given. You are also assuming that writing a feature instead of using a library is "duplicate work". It's not necessarily the case. Maybe the library approaches the problem in a much more generic way than you need. Your requirements are not "significantly different" then, just a subset of the library. > so that such critical requirements can be properly guaranteed, again probably better than you can do yourself. Are you saying that the packages available in cargo are systematically audited? I believe that the vast majority of them is not audited at all.