5 ms·
< using any number of 3rd party libraries (vs the developers desire to build from scratch) HN is strewn with stories of people with dependencies on log4j, left
by Mc91 4y ago
< using any number of 3rd party libraries (vs the developers desire to build from scratch)
HN is strewn with stories of people with dependencies on log4j, left-pad, and who knows what else. A programmer wanting to move off log4j and build logging from scratch might seem like a personal preference for some time, until the entire tech staff suddenly has to go into lockdown to remove dependencies on a dependency like log4j.
It can vary one way or the other, but if I advocate for not using a 3rd party library there is usually a good reason.
- twblalock 4y agoI would need a very strong reason to believe an internal team could build a more reliable and secure library than Log4J, and commit to support and maintain it for as long as we need it, before I would think writing an internal log library was a good idea. Outside of very large software companies, developers add business value by writing things that don't already exist. Spending time rewriting third-party libraries has dubious business value.
- bedatadriven 4y agoWriting a reliable, secure function that writes messages to stdout might be all that a project needs. The risk of third party libraries is that they often do far more than needed for an individual project. Log4j got into trouble with a feature that supported remote lookups over LDAP.
- twblalock 4y ago> Writing a reliable, secure function that writes messages to stdout might be all that a project needs. That's how it starts. Then you need to log to file. Then you need to rotate those files. Then someone asks for a custom format. Eventually you end up with a crappy internal Log4J clone.