← Back to context

Comment by prewett

7 years ago

Maybe this is my old skool C++ bias, but every time I’ve inherited a project using CocoaPods I’ve found the code to be of poor quality and the Pods to be either corporate libraries (third-party analytics, crash logs, etc.) or wrapper code of questionable quality that hasn’t really provided any benefits over a couple of hours of writing some simpler code yourself.

And you yourself mentioned Boost, which is kind a code ecosystem of its own, all open source. But I think C++ has problems with libraries because it’s such a pain to add a library to C++. If the library is C++, you can’t ship a binary and header file like with a C library because the ABI needs to match, so you have to compile the thing. And then people like Boost do template wizardry that consumes compile time to produce magic, but some developers value the compilation speed over magic, so they don’t use anything heavily templated. But if it isn’t templated, it likely could be written in C if it isn’t a big UI framework, and be available for everyone. So, no C++ library ecosystem.

Boost is awful even if you don't instantiate any templates. Just adding #include <boost/filesystem.hpp> will add 1 second to compile that compilation unit and we haven't even done anything with it.

Swift had the same ABI issues as C++, but when most packages ship as source code, it's not that big of an problem. This is precisely the thing that a standardized package manager can establish.

I think it's a bit of a catch-22. C++ projects are so rare and monolithic that reinventing the wheel every now and then. But maybe more (smaller) projects would happen in C++ if there were polished libraries for reasonably common requirements like sending a SOAP request.

  • > Swift had the same ABI issues as C++, but when most packages ship as source code, it's not that big of an problem

    ... and when there's essentially a single build system for Swift code. While for C++ there are several.

    • Having a single master, instead of having to please every compiler vendor, helps.

  • Over-edited my comment, should have been:

    > C++ projects are so rare and monolithic that reinventing the wheel every now and then...

    ...does not hurt much.