in reply to daniel:// stenberg://

This is my biggest worry too: they essentially copied the NPM package management model and practices. Good for short term productivity, but I worry that it causes significant long-term maintainability problems.

And everything is version 0.x, in part due to technical limitations of Cargo: moving out of 0.x is a breaking change, so if you have users on 0.x (which Cargo encourages by adding semver compatibility rules which make 0.x.a compatible with 0.x.b), moving out of 0.x breaks them.

This entry was edited (1 year ago)
in reply to daniel:// stenberg://

Well, it seems that your point is "Firefox consists of bad code", whereas I believe that the conclusion from the post should be "The library is bad code, which is why we are not using it in production. We'd be happy to look at their rust implementation, when it's possible"

(footnote: "bad code" being an abbreviation of "100k multi-threaded C++")

in reply to daniel:// stenberg://

To put in perspective:
- JPEG: libjpeg 6b encoder+decoder: 24,200 lines of C
- JPEG: libjpeg-turbo encoder+decoder: 127,000 of C and ASM (multi architectures)
- JPEG2000: openjpeg encoder+decoder: 50,000 lines of .C
- JPEG2000: Kakadu commercial encoder+decoder: 214,000 lines of C++ (only coresys component)
- libjxl: 150,000 lines for the core library, encoder+decoder (deps excluded)
(All above includes blank lines + inline doc)
So this is pretty much standard for a modern codec

daniel:// stenberg:// reshared this.