2 ms·
> You pull in some library - maybe it resizes images or something. It in turn pulls in image decoders and encoders that you may or may not need. They in turn pu
by lmm 2y ago
> You pull in some library - maybe it resizes images or something. It in turn pulls in image decoders and encoders that you may or may not need. They in turn pull in metadata readers, and those pull in XML libraries to parse metadata, and before you know it a fairly simple resize is costing you 10s of MB.
This is more likely to happen in C++, where any library that isn't header-only is forced to be an all encompassing framework, precisely because of all that packaging friction. In an ecosystem with decent package management your image resizing library will have a core library and then extensions for each image format, and you can pull in only the ones you actually need, because it didn't cost them anything to split up their library into 30 tiny pieces.
- nolist_policy 2y agoDo you have an example?
- barrkel 2y agoActually I think a big part of the problem in C++ is the low level of abstraction of the standard library. It isn't friction that might cause an image resizing library to be all-encompassing; it's the lack of an abstract Image class in the standard library which would enable a resizing library to live side by side with image encoders and decoders, instead of needing to bundle them together. The C++ standard library isn't rich enough. It doesn't have enough concepts for a good ecosystem of smaller components.