Remix clone Hacker News

> A lot of developers really seem to prefer janky, undermaintained third party libraries with huge APIs over a quick home made hack to solve exactly the problem your team has

Sometimes it’s not even that they’re janky and undermaintained, it’s just the huge and unnecessary API. A good example is watching for file changes. inotify has been around forever, and is easy to reason about. The Python library inotify_simple [0] just wraps that. That’s it. It works extremely well, has no dependencies of its own, and provides nothing else. I once needed this functionality for a project, and had another teammate argue we should use watchdog [1] instead, because it had more stars, and more frequent commits. It took me longer than I thought it would to explain that sometimes, projects are complete and don’t need commits, and that we didn’t need or want any of the additional complexity provided by watchdog.

Another example is UUID generation. Python doesn’t yet natively do UUIDv7 generation, but if you read their source code and the RFC for UUIDv7, it’s fairly easy to write your own implementation. This was met with “please don’t write your own UUID implementation; use a library.” Baffling.

[0]: https://github.com/chrisjbillington/inotify_simple

[1]: https://github.com/gorakhargosh/watchdog

▲

caseyohara 2 days ago | parent [-]

> This was met with “please don’t write your own UUID implementation; use a library.”

I agree with this one and I’d push back on it too.

In my experience, what will happen is you write your own UUIDv7 implementation because the language or stdlib doesn’t support it yet. Then the language eventually supports it, but this project is still using your homegrown implementation that is slightly different than the language’s implementation in an incompatible way. Lots of code is bound to your custom implementation and now it would be too much effort or cost to swap out your custom implementation for the standard one.

So now this project has a caveat: yes, it uses UUIDv7 but not the official UUIDv7 implementation, and you have to work around this land mine for the rest of the life of the project. All of these small “innocent” caveats like this add up and make working in projects like this a miserable experience.

	▲	afiori 2 days ago \| parent \| next [-]
		The point of using a standard is that it is a standard, two uuidv7 libraries should not be incompatible outside of maybe things like clock resolution
	▲	sgarland 2 days ago \| parent \| prev [-]
		That’s a fair point, but it’s also not a complex class, and could be extended to be compatible, such that swapping out for stdlib is a single import statement. For larger or more complex problems, especially those that don’t have an RFC behind them, I can definitely see the unwillingness to do so.