some guy with an opinion
kiwifarms.net
- Joined
- Mar 14, 2026
In my opinion, you've missed the point entirely.
When considering libraries, most people will always talk about the "cost" of using the library vs doing it yourself, but it's always purely considered in terms of the actual functionality of the code - who's will be the most efficient, the most rigorously tested, the most "feature complete", which handles edge cases the best, which requires the least effort, etc.
But I think the issue is a lot more fundamental and comes down to philosophy. The main point being
Any code that you use from an external library is not code that you control.
This may not sound like a large problem, but in my opinion it's the critical Achilles heel when it comes to using libraries.
You have absolutely no idea what the future of the library will be.
- Maybe someone will pull the library because they are getting sued by Kik
- Maybe an API-breaking change will be pushed in a new version, or a feature you rely on will be deprecated
- Maybe the library will have a critical vulnerability exposed, but the creator will have moved on and won't bother to fix it
Then there are more fundamental issues to do with the structure of the library and the priorities of the developer
- Does the library expect data to conform to a specific format to make things easier for the library maintainer, but meaning more conversions for you
- Does the library respect the rules of my project - if I want to pass consts around everywhere and ensure consistency of data because it's important, how do I know the library won't randomly change things?
Even if you do your due diligence and thoroughly research a library before choosing it, you don't know how it's going to change in the future.
Even if you use purely offline, static versions of libraries, maintain your own collection of .o files for them (or whatever), and generally only use them in an environment where you control how and when they update or change, you still have no guarantees about whether or not they will do what you need them to unless you read through the source code thorougly and understand exactly what the library is actually doing. Once you've expended the energy to fundamentally understand the entire library, you might as well have written it yourself - at least if you write it yourself you'll know that you have something tailor-made to fit your needs. This is especially if the library has licensing terms that now mean you owe royalties or are hamstrung in some other way.
People will say things like "Why write my own string library when I can just download and use left-pad to have a quicker and more efficient string library that's known to work because of all the field testing that it's already gotten?", and they don't actually consider that you are ALWAYS beholden to the library creator, no matter how much better you might think the library is.
Now consider that it's essentially standard practice across the industry for a typical piece of business software to use thousands of third-party libraries, and suddenly you'll realise you have absolutely no control over your own codebase. All you're doing is passing requests between things other people control. Your code is essentially an employee working on behalf of the libraries.
This is why I will *always* prefer to write my own string library. Even if it's less efficient and field tested.
Every library you add to your project is a liability and should be treated as such. Even if you use an offline version and aren't at risk of it being pulled or changed in detrimental ways, you are still constrained by the requirements of the library, and it's still fundamentally a black box that you're essentially being expected to operate within, which adds uncertainty. Each library you decide to use should be carefully considered and should be absolutely avoided at all costs unless it's absolutely necessary to include. "Getting better code by getting someone else to do it" is a false economy, exactly how companies outsourcing work to "make it cheaper" is a false economy. They both share the same fundamental problems and if you don't support one you shouldn't support the other.
I understand there are situations in which using libraries makes sense and is necessary. For something where security is absolutely critical and requires a specific skillset it's better to let someone who knows what they are doing handle it rather than trying to roll your own. For extremely complex, domain-specific use cases like rendering, it makes sense to use OpenGL or Vulkan or DirectX rather than writing the entire rendering stack by yourself. Using a library makes sense when the workload is otherwise astronomical or extremely prone to error without specific expertise and a lot of oversight. In these cases, however, the right approach is always to treat the library as a hostile entity that's trying to infect and take over your codebase, which essentially means isolating it to one specific part of the code. If you need to interact with it it, use a a generic interface that you create, and ensure you can remove that library and replace it with something else at a moments notice which can be made to conform to the interface. Do not use the data objects provided by the library, instead you should always convert to your own ones and then use those throughout the codebase, rather than casually peppering dependencies around your code files like landmines. The number of companies I have worked for that are "stuck" using some dead library from some dead software vendor that's only giving them trouble but "our whole system depends on it" is countless. And it always sucks for everyone. These issues could have been avoided if these companies isolated their libraries.
For the case of left-pad specifically, it seems insane and asinine to me why any programmer would take on the significant risks and lack of control that adding a library adds, simply so they could save 10 minutes of work. Seriously. It takes less than 10 minutes of work to write a left-pad function. The entire library is literally only 11 lines! And there are countless examples online of people writing better versions - these people are not experts on string manipulation, nor have they written string libraries, they are simply competent programmers trying to do the best work possible. Why would anyone trade 11 lines of code for a permanent dependency that can blow up in their face at any moment, as it famously did for so many projects. If you seriously use left-pad, or you seriously advocate for the use of left-pad, you are a bad programmer and are doing both yourself and the industry at large a disservice by using it and recommending it. Stop it!
This isn't even taking into account the fact that the typical "someone else will do the job better so I should use their library!" argument is inherently an anti-intellectual position. If you're not good at something, take the time to learn it. Relying on libraries to do everything for you makes you stupid and a bad programmer. Would you trust a car mechanic that "finds working on cars too complex" and does everything through a third party?
Seriously, stop using libraries. They essentially force you to code on someone else's terms, take control of your own codebase away from you and give it to someone else, and make you into a crappy programmer. There's a reason why the quality of so much software nowadays can be determined literally by the number of libraries it's using. Often people blame "bloated libraries", but it's not just because libraries are bloated, it's so often because the developers themselves are not competent programmers and aren't expected to be competent programmers - anything they can't handle they simply outsource (if not to pajeets, then to some library most likely written by pajeets), and they refuse to learn the skills needed to actually understand and maintain their own codebase. As a result, when library issues arise, they are not equipped to fix it, and it's very easy for subtle impossible-to-fix bugs to crop up in projects over time that use a large number of libraries. If they don't fundamentally understand the code, how can they expected to fix it when it goes wrong?
Last edited:
)
