> we are really proud to have got it working at all
On the contrary, the rust crate ecosystem and tooling means a lone developer can compose specialised libraries to produce a working artefact that scratches her own itch. Such productivity is the opposite of getting something working at all.
Trying to build an OSS cpp project or even worse, use an OSS Cpp library in your own project is more along the lines of "getting something working at all". Every third-party and some enterprise-internal Cpp libraries require one answers the following questions:
- how do I build the damn thing?
- how do I run the tests?
- how do I use the library? Vendor into the repo? apt install?
- what APIs does the system/library provide?
- where can I find the documentation and examples?
- how do I set up code completion?
- how do I know am using the library interface correctly?
- how do I know I didn't violate any invariants/safety guarantees?
Compare with the list of dependencies across the Cargo workspace members.
The cost of adding a new rust dependency when measured by the number of questions you need to answer beforehand is nearly constant. This means a layman can be more productive in rust.
Correct use, documentation, and other concerns are imporant for all libraries, whether got via cargo or otherwise, so this amounts to special pleading again.
More importantly, though: how hard is it to use a library coded in C++ from your Rust program? You have to make and maintain some sort of shim layer. Even a C library needs some such effort. For any given need, you are much less likely to find an existing and suitable Rust library already written, released, and maintained than one in some other, more widely used, language.
Coincidentally, the above linked crate `libloading` also shows how to access functionality in a shared library that exposes a C ABI compatible interface whatever the implementation language.
On the contrary, the rust crate ecosystem and tooling means a lone developer can compose specialised libraries to produce a working artefact that scratches her own itch. Such productivity is the opposite of getting something working at all.
Trying to build an OSS cpp project or even worse, use an OSS Cpp library in your own project is more along the lines of "getting something working at all". Every third-party and some enterprise-internal Cpp libraries require one answers the following questions:
- how do I build the damn thing?
- how do I run the tests?
- how do I use the library? Vendor into the repo? apt install?
- what APIs does the system/library provide?
- where can I find the documentation and examples?
- how do I set up code completion?
- how do I know am using the library interface correctly?
- how do I know I didn't violate any invariants/safety guarantees?
Compare with the list of dependencies across the Cargo workspace members.
https://github.com/lapce/lapce/blob/master/lapce-core/Cargo....
https://github.com/lapce/lapce/blob/master/lapce-ui/Cargo.to...
https://github.com/lapce/lapce/blob/master/lapce-rpc/Cargo.t...
The cost of adding a new rust dependency when measured by the number of questions you need to answer beforehand is nearly constant. This means a layman can be more productive in rust.