It's ironic because the Rust experience is proving that the real reason Java (as well as Visual Basic, and other languages of that generation) was a breakthrough in code reuse was not the trappings of OO programming such as polymorphism and inheritance but the garbage collector.
Code reuse in C and C++ is limited by memory management being a global concern of a program. Ideally a library could get buffers from the application when that is appropriate, but may need to allocate memory for itself if it is building complex interlinked structures. A library can't be sure if the application still needs a buffer and the application can't really be sure.
For the most part, libraries in the C world are impoverished, they avoid doing things that require complex memory management.
With the garbage collector, allocation becomes a local problem (just do it) and freeing is handled for you globally (buffers get reused when no longer needed.)
Rustifarians are struggling because the problem of memory allocation is reframed as a fight with the borrow checker, and that problem is a global problem that involves both the application and all of the libraries it depends on. They're facing the choice between an impoverished model for memory as seen in C libraries and the intractable problem of combining multiple strategies for borrowing as applications + libraries grow in scale.
Code reuse in C and C++ is limited by memory management being a global concern of a program. Ideally a library could get buffers from the application when that is appropriate, but may need to allocate memory for itself if it is building complex interlinked structures. A library can't be sure if the application still needs a buffer and the application can't really be sure.
For the most part, libraries in the C world are impoverished, they avoid doing things that require complex memory management.
With the garbage collector, allocation becomes a local problem (just do it) and freeing is handled for you globally (buffers get reused when no longer needed.)
Rustifarians are struggling because the problem of memory allocation is reframed as a fight with the borrow checker, and that problem is a global problem that involves both the application and all of the libraries it depends on. They're facing the choice between an impoverished model for memory as seen in C libraries and the intractable problem of combining multiple strategies for borrowing as applications + libraries grow in scale.