←back to thread

295 points todsacerdoti | 5 comments | | HN request time: 0.968s | source
Show context
Aperocky ◴[] No.45948201[source]
> the era of small, low-value libraries like blob-util is over.

Thankfully (not against blob-util specifically because I've never intentionally used it), I wouldn't completely blame llms either since languages like Go never had this dependency hell.

npm is a security nightmare not just because of npm the package manager, because the culture of the language rewards behavior such as "left-pad".

Instead of writing endless utilities for other project to re-use, write actual working things instead - that's where the value/fun is.

replies(3): >>45948291 #>>45948576 #>>45956235 #
ncruces ◴[] No.45948291[source]
But as Go puts it:

“A little copying is better than a little dependency.”

https://go-proverbs.github.io/

replies(2): >>45948486 #>>45948539 #
threatofrain ◴[] No.45948539[source]
Copying is just as much dependency, you just have to do maintenance through manual find-and-replace now.
replies(7): >>45948640 #>>45948666 #>>45948754 #>>45948756 #>>45949127 #>>45949152 #>>45949481 #
1. ninkendo ◴[] No.45948756[source]
> you just have to do maintenance through manual find-and-replace now

Do you? It doesn't seem even remotely like an apples-to-apples comparison to me.

If you're the author of a library, you have to cover every possible way in which your code might be used. Most of the "maintenance" ends up being due to some bug report coming from a user who is not doing things in the way you anticipated, and you have to adjust your library (possibly causing more bugs) to accommodate, etc.

If you instead imaging the same functionality being just another private thing within your application, you only need to make sure that functionality works in the one single way you're using it. You don't have to make it arbitrarily general purpose. You can do error handling elsewhere in your app. You can test it only against the range of inputs you've already ensured are the case in your app, etc. The amount of "maintenance" is tiny by comparison to what a library maintainer would have to be doing.

It seems obvious to me that "maintenance" means a much more limited thing when talking about some functionality that the rest of your app is using (and which you can test against the way you're using it), versus a public library that everyone is using and needs to work for everyone's usage of it.

replies(1): >>45949664 #
2. jorvi ◴[] No.45949664[source]
> If you're the author of a library, you have to cover every possible way in which your code might be used.

You don't actually. You write the library for how you use it, and you accept pull requests that extend it if you feel it has merit.

If you don't, people are free to fork it and pull in your improvements periodically. Or their fork gets more popular, and you get to swap in a library that is now better-maintained by the community.

As long as you pin your package, you're better off. Replicating code pretty quickly stops making sense.

replies(1): >>45949957 #
3. marcus_holmes ◴[] No.45949957[source]
It's a rare developer (or human for that matter) who can just shrug and say "fork off" when asked for help with their library.
replies(2): >>45950596 #>>45953253 #
4. j1elo ◴[] No.45950596{3}[source]
It would be healthy that it becomes more common, in fact the privately-owned public garden model of the Valetudo project [1] is the sanest way for FOSS maintainers to look at their projects.

[1]: https://github.com/Hypfer/Valetudo#valetudo-is-a-garden

5. jorvi ◴[] No.45953253{3}[source]
It really depends. If it's the occasional request and I can bang out a solution in 30 minutes, I'll help. But I'll also weigh how much maintenance burden it'll be going forward. And if I won't do it myself, I'd always give some quick pointers.

Maintenance demands (your library X doesn't work with Python Y, please maintain another version for me) I'd shrug off. Wait for me, pay me, or fix it yourself.