3 ms·
StableLib https://stablelib.com/ https://stablelib.com/ seems to be taking an interesting approach to libraries. Go guarantees backwards compatibility and it's
by nulltype 11y ago
StableLib https://stablelib.com/ https://stablelib.com/ seems to be taking an interesting approach to libraries. Go guarantees backwards compatibility and it's awesome for developers. Why shouldn't libraries have the same guarantees?
The standard library is pretty nice, but one of the reasons for that is that it is a well tested well supported backwards compatible library. It would be nice if there were more of those.
- acveilleux 11y agoIt's pretty much a given that the first few libraries solving problem X will have a sub-optimal API, especially if they aim to be both general (say read and display JPEG) and full-featured (support all the optional bits of the format or work efficiently in low-memory embedded situations, etc.) at the same time. All of that while preserving the feel and idioms of the host language. This is key since it invalidates a lot of prior experience with similar APIs. So until the "right" API coalesces from collective experience with the problem domain and APIs for similar libraries (read and display {TIFF, GIF, PNG, etc.} in $LANGUAGE) backward compatibility is not a feature you want. Wait for the second or third wave of libraries where the problem is solved and understood in a nice idiomatic way for the language and its quirks.
- nulltype 11y agoPerfect is the enemy of good I guess. If I'm building a product now, I want a library that works well now and never breaks when I upgrade to the latest version. If someone gets a great idea for a better library, make it a separate library. So backwards compatibility is definitely a feature I want.