there is an important third category of options, which is to reproduce the desired functionality of a library.
good text handling is important to users, so it is equally important that more programmers practice the implementation of good text-handling libraries (from scratch).
Conversation
With all due respect, this is implying that English speakers can write, say, Arabic text handling just as well as Arabic speakers can. Not only is this false, this sentiment has ugly cultural implications.
2
3
Expecting everyone to contribute to one monolithic culture has its own problems. Would building a software ecosystem for Arabic speakers be easier if it didn't need to fit in Latin-centric infrastructure?
1
I think this is key to argument: _small_ deps are the concern, and the putative "harm done" by rewriting a dep (because you don't trust it or simply don't _like_ it -- deps are always a bit of an imperfect fit) is proportional to the dep's size. Big deps matter, but are accepted.
1
1
6
I dunno. libsodium is a small dependency. But rewriting that puts users at risk.
2
1
This Tweet was deleted by the Tweet author. Learn more
Crypto is no less dangerous to rewrite if it’s 20 lines or 200.
3
It can also be dangerous to reuse code that's poorly implemented or maintained. This is particularly true with cryptography. I often see libraries as a painful compromise because I know I could do a better job if I had the time to invest. Sometimes I can't make that compromise.
2
2
For example, over the years, I've found myself rolling my own sessions for web services, because it's too important to leave it to someone else and I can never find any options doing it up to my standards. It doesn't need cryptography beyond a standard CSPRNG when done right.
1
It depends a lot on the language ecosystem. In some languages, I try to find a library to fit a use case and I can't find anything that's properly maintained or meets my standards. This happens a lot with the traditional Java ecosystem. Each dependency also gives me concern.
1
2
There are currently 2 library dependencies in my projects that are unmaintained. I lack the time to take over maintenance and it's painful to invest the time moving to other libraries. One of these depends on another library that's in a fairly concerning maintenance-only mode.
In a past project that I've handed off to someone else, the upstream project is hostile towards non-GNOME usage despite it being presented as a general purpose library for others. They regularly strip out necessary functionality and it has to be patched to expose private APIs.