Why are libraries not sufficient?
It depends on the circumstances. EIP-2535 Diamonds is used for multiple things: code organization, modularity, fine grained upgrades, reusable on-chain code, smart contract protocol extension, stable address without a limit of the number of external functions. It does not replace Solidity libraries.
Correct me if I am wrong but I believe that libraries can do the following:
- code organization, yes libraries allow this
- modularity, yes
- fine grained upgrades, libraries and/ or contract can be upgraded with OZ but maybe not to the degree of Diamond
- reusable on-chain code, the main reason libraries exist
But not these:
- smart contract protocol extension,
- stable address without a limit of the number of external functions.
Edit: but I am looking for explaination that libraries can or cannot alleviate 24kb contract size limit. Please show me the where in docs this is shown
Yes, Solidity libraries can be used to help with these things.
EIP-2535 Diamonds is a general smart contract architecture for designing extensible smart contract systems. Solidity libraries are a programming language feature, not a contract architecture, though architectures could be designed that use them.
Solidity libraries are a tool for creating reusable deployed on-chain code. EIP-2535 Diamonds answers questions like this: How do I design an upgradeable smart contract system that can be easily extended in production without limit? It so happens that EIP-2535 Diamonds natively supports and solves some of the same problems that Solidity libraries do.
Solidity libraries work very nicely with diamonds, specifically using internal functions of Solidity libraries to share functions between facets. External functions from Solidity libraries can be used with diamonds too.
Edit: but I am looking for explaination that libraries can or cannot alleviate 24kb contract size limit.
Solidity libraries can be used to alleviate the 24kb contract size limit but its ability to do so is limited. External functions defined in a contract generate bytecode. So if enough external functions are added to a contract then it will hit the 24kb contract size limit. A diamond can have practically an unlimited number of external functions. This enables deployed contract system to be extended without risk of hitting a technical limit in the future.
Using Solidity libraries to reduce bytecode size means reorganizing code to get around a technical limitation rather than reorganizing code to make it better or more organized. A developer may not want to organize her code based on a bytecode size limitation. On the other hand perhaps contract architectures can be designed that use Solidity libraries in a way that is nice and not likely to hit the bytecode size limit. EIP-2535 Diamonds is a solution like that: it uses delegatecall like Solidity libraries do.