I could not disagree more. There is no reason for me to bother implementing all the possible API and edge cases around figuring out the size of a terminal, when I can simply call in someone else's...
I could not disagree more. There is no reason for me to bother implementing all the possible API and edge cases around figuring out the size of a terminal, when I can simply call in someone else's code that will do it better. This is true for pretty much all crates. I don't think having dependencies and running cargo update twice a year is worth reinventing the wheel over and over and over.
This is a great point, and I think it's what the article is basically arguing against. I think that the actual "answer" to the question of "should I code it myself or just grab a library" is in...
This is a great point, and I think it's what the article is basically arguing against.
I think that the actual "answer" to the question of "should I code it myself or just grab a library" is in the middle of these two extremes. Sometimes it's important to just grab something and use it, and then you can fit maintenance into things on a monthly (or semi-annually? That seems low to me) basis. But sometimes you want to deploy and avoid churn. Knowing the difference between when to do one vs the other is one of the defining characteristics of a good senior developer.
I actually think Ronacher's example of terminal size is a really carefully picked and great example of an instance in which there is a good argument for writing your own code. It is generally not particularly difficult to figure out the terminal size; as said in the article, the API for doing so is both very old and very stable, so it's not likely to change. Figuring out the size of your terminal - a very stable, very old, very known thing - should probably not introduce monthly maintenance to your project. And the library contains a lot of things that one might not need for a project, which should be considered. For example, for most of my own projects, I am never going to need to know the terminal size of a Windows terminal, so having that included is just cruft. For some projects - if I'm writing to share, for example - then that might be important to include. I'd make that call on a project by project basis.
I think it's summed up almost perfectly in this line:
But when you end up using one function, but you compile hundreds, some alarm bell should go off.
Sometimes developers end up including thousands of lines of code in a library when they could write 50 lines of code and have something faster and more stable. I think it's probably important for people to at least listen to the quoted text; if you just want something very simple, such as terminal size, and you end up creating a chain of required maintenance, then maybe it's okay to not include the library, and just code what you need.
My metrics for judging when to hand-roll vs import are more or less: How much value is being added? How likely is it that this library will screw things up (e.g. throw compiler errors) in the...
My metrics for judging when to hand-roll vs import are more or less:
How much value is being added?
How likely is it that this library will screw things up (e.g. throw compiler errors) in the future?
If it does eventually break something, how confident am I that I’ll be able to crack it open, navigate its code, and fix it in a timely manner?
How many other dependencies is this library roping in?
Generally speaking, this has lead me to only pull in libraries when they’re little more than syntactic sugar wrapping things that come with the language/platform or when they’re adding a big chunk of functionality that I’m not likely to implement quickly or well (think HTML manipulation or IMAP server interaction). Otherwise, whenever feasible I write my own.
Of course, it is not all black and white, as is mentioned in the article. But is it better? How do you know it is better? No-one has a problem with deciding to add a dependency after careful...
Of course, it is not all black and white, as is mentioned in the article.
There is no reason for me to bother implementing all the possible API and edge cases around figuring out the size of a terminal, when I can simply call in someone else's code that will do it better.
But is it better? How do you know it is better?
No-one has a problem with deciding to add a dependency after careful vetting has shown that in the long term it is a better option than writing it yourself. But we all know that is not how it works. The dependency is added because it is easy, not because it is actually necessary. This is not just about security, or the quality of the code, but also about the amount of functionality the dependency covers. If you need only one function, just copy and paste it and leave the rest out.
But just adding one line that imports the whole package is oh so easy. In the long term, that causes more harm than most people realize, and I think the author is right in trying to combat that.
This used to be (somewhat sarcastically) referred to as a dichotomy between "not invented here" vs "proudly invented elsewhere," before the "proudly invented elsewhere" folks won. The modern...
This used to be (somewhat sarcastically) referred to as a dichotomy between "not invented here" vs "proudly invented elsewhere," before the "proudly invented elsewhere" folks won. The modern open-source community and culture is pretty great, but I think the author is right that we need to recalibrate a little more towards the "not invented here" side of things. To me it's often a sign of a weaker or less experienced dev when someone is constantly looking for new libraries, rather than thinking about how to build functionality themselves.
I could not disagree more. There is no reason for me to bother implementing all the possible API and edge cases around figuring out the size of a terminal, when I can simply call in someone else's code that will do it better. This is true for pretty much all crates. I don't think having dependencies and running
cargo updatetwice a year is worth reinventing the wheel over and over and over.This is a great point, and I think it's what the article is basically arguing against.
I think that the actual "answer" to the question of "should I code it myself or just grab a library" is in the middle of these two extremes. Sometimes it's important to just grab something and use it, and then you can fit maintenance into things on a monthly (or semi-annually? That seems low to me) basis. But sometimes you want to deploy and avoid churn. Knowing the difference between when to do one vs the other is one of the defining characteristics of a good senior developer.
I actually think Ronacher's example of terminal size is a really carefully picked and great example of an instance in which there is a good argument for writing your own code. It is generally not particularly difficult to figure out the terminal size; as said in the article, the API for doing so is both very old and very stable, so it's not likely to change. Figuring out the size of your terminal - a very stable, very old, very known thing - should probably not introduce monthly maintenance to your project. And the library contains a lot of things that one might not need for a project, which should be considered. For example, for most of my own projects, I am never going to need to know the terminal size of a Windows terminal, so having that included is just cruft. For some projects - if I'm writing to share, for example - then that might be important to include. I'd make that call on a project by project basis.
I think it's summed up almost perfectly in this line:
Sometimes developers end up including thousands of lines of code in a library when they could write 50 lines of code and have something faster and more stable. I think it's probably important for people to at least listen to the quoted text; if you just want something very simple, such as terminal size, and you end up creating a chain of required maintenance, then maybe it's okay to not include the library, and just code what you need.
My metrics for judging when to hand-roll vs import are more or less:
Generally speaking, this has lead me to only pull in libraries when they’re little more than syntactic sugar wrapping things that come with the language/platform or when they’re adding a big chunk of functionality that I’m not likely to implement quickly or well (think HTML manipulation or IMAP server interaction). Otherwise, whenever feasible I write my own.
Of course, it is not all black and white, as is mentioned in the article.
But is it better? How do you know it is better?
No-one has a problem with deciding to add a dependency after careful vetting has shown that in the long term it is a better option than writing it yourself. But we all know that is not how it works. The dependency is added because it is easy, not because it is actually necessary. This is not just about security, or the quality of the code, but also about the amount of functionality the dependency covers. If you need only one function, just copy and paste it and leave the rest out.
But just adding one line that imports the whole package is oh so easy. In the long term, that causes more harm than most people realize, and I think the author is right in trying to combat that.
This used to be (somewhat sarcastically) referred to as a dichotomy between "not invented here" vs "proudly invented elsewhere," before the "proudly invented elsewhere" folks won. The modern open-source community and culture is pretty great, but I think the author is right that we need to recalibrate a little more towards the "not invented here" side of things. To me it's often a sign of a weaker or less experienced dev when someone is constantly looking for new libraries, rather than thinking about how to build functionality themselves.