11 ms·

Interesting how any company with enough C++ developers will eventually develop a huge library like that (with data structures and tools and system wrappers). In

Interesting how any company with enough C++ developers will eventually develop a huge library like that (with data structures and tools and system wrappers). In the JS ecosystem, we may complain that node_modules is large, but at least we are not reimplementing and rewrapping the wheel at every corp (same for python). Maybe if C++ had a standard package manager, people would stop coding huge libraries like that, focusing on smaller libraries that can be reused (independently).

jakearmitage 7y ago
If you're using C++, you want speed and/or memory efficiency. Generic libraries won't give you that. You need custom implementations of data structures that make the trade-offs relevant to your needs.
- antoineMoPa 7y ago
  There is no reason for memory or speed to be different. What I mean is that parts of these libraries could be single small packages that would be as fast. As an example, look at this folder which: https://github.com/facebook/folly/tree/master/folly/compression https://github.com/facebook/folly/tree/master/folly/compress... In short, these are compression tools. Why not have 1 easily uninstallable package per compression tool in a standard package manager that works the same on all platforms. Things don't have to be more or less generic.
  - Eyas 7y ago
    So the comment is really about the size of these libraries? This is more of an artifact of companies that produced them, which use large monorepos, than the ecosystem itself. That said, you can pick and choose which part of boost you use, just as you can pick and choose which part of Abseil/Folly you use.
  - forrestthewoods 7y ago
    > Why not have 1 easily uninstallable package per compression tool in a standard package manager that works the same on all platforms. Because C++ sucks and its dependency story is a nightmare. There are a few competing C++ package managers. They’re all relatively new and none of them are particularly popular. The most widespread C++ libraries are ones that are single header files. Because that’s the only thing that’s trivial to implement into an existing project. Compiling OpenSSL requires installing Strawberry Perl. This type of garbage of BS is the norm. Source: C++ dev for 15 years
    - asveikau 7y ago
      > The most widespread C++ libraries are ones that are single header files. Because that’s the only thing that’s trivial to implement into an existing project. I think this has much more to do with templates than anything else. A template can only exist in a header. Then there is also the performance benefit of inlining. (As well as performance hit of inlining, namely code size.) There is a separate, much later movement/phenomenon of C (not C++) developed as header-only libraries, which by contrast I don't think there is nearly as good reason for except for that some people are confused at how a linker works. I have seen use of that technique advocated on Hacker News much more frequently than in production.
      - forrestthewoods 7y ago
        Header only and single file are slightly different. A headery library may include many many files. A single file or single header may be “header only” or it may have an impl define. People who prefer this distribution mechanism are generally ok with 1 header plus 1 cpp. These libraries generally have no third party dependencies. Because tracking down and compiling C++ dependencies is a dumpster fire.
        asveikau 7y ago
        Or maybe they don't actually need the dependencies. There is a style of writing code to minimize dependencies and many people value this. I would take the sqlite amalgamation as an example of good use of "few files, few dependencies". First off, it is above all a solid piece of work. It is distributed with one header file and one .c, even though it is developed as multiple files. Iirc the sqlite website cites a ~10% speed improvement or so due to the optimizer being able to do a better job across the whole library. In my opinion this is a better reason than "tracking dependencies sucks" or "omg too many files".
- msla 7y ago
  > If you're using C++, you want speed and/or memory efficiency. Generic libraries won't give you that. The standard libraries should, in that they can have Spooky Deep Knowledge of the compiler and other standard libraries which external code won't, like how there's no way to add two ints which is faster than the standard + operator.
  - jeffreygoesto 7y ago
    Well, this argument goes both ways, a generic implementation can never leverage special properties of your data. See i.e. Alexandrecu's talk [0] at about 1:05ff. If as a company you have special use cases or guidelines, you may easily benefit from libraries using these properties. [0] https://youtu.be/FJJTYQYB1JQ https://youtu.be/FJJTYQYB1JQ
  - danbolt 7y ago
    I think you're right that some things, such as integer addition, are quick and don't require a lot of thought, but a lot of teams leaning to C++ stems from larger-scale performance considerations that aren't one-size-fits-all. A simple example is `std::vector`. The structure is a nice resizable array, but for a long time you couldn't override the allocator and the performance of your application could be affected by heap fragmentation or even just the performance cost of heap allocations. A lot of C++ shops often wrote their own replacement containers that had a better allocation strategy. The design needs of a PlayStation 2 programmer ended up being different than an x86 desktop computer with virtual memory.
m463 7y ago
I think another possibility might be to continually "roll" new wheels into the standard library. python question: Do people re-implement a lot of the core library routines at every company? Compared to other scripting languages, I found python to have a pretty large/compatible standard library (except when they renamed the url/configparser module names)
- bluGill 7y ago
  Python is generally not used for the types of hard problems where a company specific library would help. When performance or code size matters you leave python for something else. Thus C++ will get libraries anytime the standard library had to make a tradeoff that isn't always right. Python by making the tradeoff for features has limited itself out of places where you would trade less features for something else. This is great for python as it wouldn't play well in the less features space anyway. I expect to see company specific libraries for rust at some point because rust can play in the same space as c++ where you might want to make a different trade off.
  - fulafel 7y ago
    I think this is a one sided view of Python, even though its true that it's most often used for easy problems. Eg Dropbox and Youtube are using Python, solve hard probs, probably have proprietary libs, and care about code speed.
quicklime 7y ago
I would argue that any company with enough JavaScript developers will eventually develop JS libraries too. There's nothing that limits this to just C++. Facebook has folly but also react and a whole set of tools around it.
- BoorishBears 7y ago
  This is more like if every company reimplemented core-js... worth a little more examination than "large companies write libraries"
  - otabdeveloper4 7y ago
    React attempts the re-implement the browser DOM API and its associated UI conventions. That's way more WTF than folly, which is basically jQuery for C++.
    - BoorishBears 7y ago
      React attempts to wrap the browser DOM API and it's conventions in a way that's (for people who use it) easier to reason about, that's kind of like saying Anvil is a WTF because it wraps Vulcan Also yeah, every reimplementing jquery would be extremely strange and mostly defeat the point of jquery... which is to not have to implement jquery's constructs in Vanilla JS
- mattigames 7y ago
  I don't think I agree, most don't reinvent the common parts: jQuery, lodash, angular or react
  - quicklime 7y ago
    Most don't, but Facebook does have its own equivalent of jQuery, lodash and angular. A few other very large tech companies are similar. Most C++ shops don't have their own equivalent of Folly, they use Boost or Google's Abseil or something else.
notacoward 7y ago
C++ does have a standard package manager. It's the system package manager, instead of a language-specific one. Whether that's good or bad is a matter for some debate, but it does exist.
- BoorishBears 7y ago
  > C++ does have a standard package manager. It's the system package manager, instead of a language-specific one. So C++ does not have a standard package manager. Or are we really going full HN and debating the meaning of the word standard? Even if we are... is there a standard system? For that standard system, is there a standard package manager?
  - notacoward 7y ago
    You're the only one trying to play with definitions of "standard" here. The system package manager was the standard packaging method for extra functionality on Linux (and other) systems regardless of implementation language before perl/Python/etc. started coming up with their own. You might argue that it's a bad standard, that it doesn't work for more "nimble" languages, whatever, but it is how C++ code is supposed to be packaged and has been for a long time. What C++ doesn't have is an exclusive package manager that can't be used with other languages. Non-exclusivity doesn't make anything less standard. Quite the contrary.
    - BoorishBears 7y ago
      This is not how language works. You don't get to just slice up a sentence and then talk to the parts that suit you "C++ does not have a standard package manager." C++. The language. Does not have a standard package manager. From your own comment: > It's the system package manager, instead of a language-specific one You're literally admitting C++ does not have a package manager right there and then saying it's up to the system to fill in that gap! - This is a seriously mind-numbing conversation because all your replies make it clear you know EXACTLY what they mean, yet you're so focused on being the obligatory contrarian who has to proudly proclaim C++ has been done the way it's done and that's a fine way (and won't go so far as to say it's the correct way because deep down we all know it's not, but will always go right up against that line and pull out the "well it worked for all that C++ code out there" if you push back) and all you kids with your nimble languages can say it's bad but you just don't get it. This is why for my mental sanity I try to refrain from talking about the meta situation of C++. The language, not the system. To be clear.
Rexxar 7y ago
Maybe it's because the language give you all the tools to do it without any performance penalty. This allow you to have a custom library that is fit to your needs instead of a standard library that is globally good but obviously not optimal in all situations.
doctorsher 7y ago
It may not be "standard", but Conan is a C++ package manager which IMHO is quite nice to work with. Not affiliated in any way.
asveikau 7y ago
I feel a bit like there is some kind of programming totalitarian personality that wants there ever to always to be one thing. There are so many build systems in C and C++ because for each of those, someone finds something to be inadequate and has something else that works for them. Just like there is no standard for sizeof(int) or whatever, because it started with one size on one CPU and somebody brought it to a different CPU where another size made better sense. Today you can usually guess that it's 32 bits, but there are domains where it's not. These languages are meant to not impose a lot on the implementer or practitioner. Having the standard specify that every build needs to potentially pull down a bunch of crap from github or wherever else is going to be really annoying to a lot of people. It is a misguided suggestion. I think it mostly comes from people not working in the language, or unfamiliar with code bases that are working well as-is.
- antoineMoPa 7y ago
  I said there should be a standard package manager, this does not mean that it has to be the only one. It would just be easier for everyone if there was a widely adopted way to package, install and update stuff, like most modern languages.
  - fit2rule 7y ago
    There is such a thing for C/C++ devs: Git. This works so well you may have hardly even noticed its so widespread as a solution to the problems you describe.
- msla 7y ago
  > Just like there is no standard for sizeof(int) or whatever, because it started with one size on one CPU and somebody brought it to a different CPU where another size made better sense. Today you can usually guess that it's 32 bits, but there are domains where it's not. This is different: C has to be implemented efficiently on a wide range of hardware, almost without regard for how good of a fit that hardware is for C or any modern language. Machines with 36-bit integers and 18-bit pointers? They got C compilers. Machines with no native notion of byte addressability? Plenty of C compilers for those things. Machines with application-visible segmentation? Of course! Those machines were quite popular for a while. Therefore, the C programming language has to at least try to make it possible for portable programs to exist. That's the implied contract of the C standard: Code to the standard, and your programs will be compilable and runnable on every platform targeted by a conformant C compiler. So, since int is going to be a size adapted to the hardware, as required for efficiency, the programs have to know how big an int is, as required for portability. > Having the standard specify that every build needs to potentially pull down a bunch of crap from github or wherever else is going to be really annoying to a lot of people. No language standard specifies that, I'm pretty sure. The ES6 standard doesn't specify left_pad and the C++ standard doesn't specify Boost. However, the standards also don't specify things which could replace those external libraries in a portable fashion which is guaranteed to always be there. If you take something out of the standard library, it has to go somewhere; people aren't going to stop doing that thing just because the standard no longer mentions it.
ivanhoe 7y ago
And then some dude somewhere deletes from repo his lib for left padding a string, and no one in the whole Facebook can compile anything until it's resolved? There's a reason why big companies like to have a full control over their code. Also it makes licensing a lot easier and legally safer.
ccktlmazeltov 7y ago
Rust has a package manager, and yet I predict that the same thing is going to happen as the standard library is pretty thin and lacking. The reason is trust, you can't trust random third party dependencies if you're writing sensitive code, it's easier to trust a std lib OR something that pretends to replace/add to it from serious people.
- skyde 7y ago
  Why do you think Rust would be different from Java or C#. I believe that both Java and C# are doing a good job at sharing package using Maven and Nuget.
wrsh07 7y ago
I don't think this is a particularly interesting take. Google's utility c++ library isn't that different from eg underscore.js (or lodash) Google uses some boost code and plenty of other external libraries (I can't speak to Facebook but imagine it's similar) - I think the point is just that Facebook and Google have an enormous amount of c++ code and have thus created libraries (some of which are fundamental enough or self-contained enough to open source) This is just what happens when a bunch of engineers are all working in the same language - the utility libraries become large enough, robust enough and useful enough to open source ----- As an aside, I think the similarities between folly and absl say something more meaningful about the state of c++
skyde 7y ago
thats why Rust might win in the long run because it have a common build system and package manager

jakearmitage 7y ago

If you're using C++, you want speed and/or memory efficiency. Generic libraries won't give you that. You need custom implementations of data structures that make the trade-offs relevant to your needs.

antoineMoPa 7y ago
There is no reason for memory or speed to be different. What I mean is that parts of these libraries could be single small packages that would be as fast. As an example, look at this folder which: https://github.com/facebook/folly/tree/master/folly/compression https://github.com/facebook/folly/tree/master/folly/compress... In short, these are compression tools. Why not have 1 easily uninstallable package per compression tool in a standard package manager that works the same on all platforms. Things don't have to be more or less generic.
- Eyas 7y ago
  So the comment is really about the size of these libraries? This is more of an artifact of companies that produced them, which use large monorepos, than the ecosystem itself. That said, you can pick and choose which part of boost you use, just as you can pick and choose which part of Abseil/Folly you use.
- forrestthewoods 7y ago
  > Why not have 1 easily uninstallable package per compression tool in a standard package manager that works the same on all platforms. Because C++ sucks and its dependency story is a nightmare. There are a few competing C++ package managers. They’re all relatively new and none of them are particularly popular. The most widespread C++ libraries are ones that are single header files. Because that’s the only thing that’s trivial to implement into an existing project. Compiling OpenSSL requires installing Strawberry Perl. This type of garbage of BS is the norm. Source: C++ dev for 15 years
  - asveikau 7y ago
    > The most widespread C++ libraries are ones that are single header files. Because that’s the only thing that’s trivial to implement into an existing project. I think this has much more to do with templates than anything else. A template can only exist in a header. Then there is also the performance benefit of inlining. (As well as performance hit of inlining, namely code size.) There is a separate, much later movement/phenomenon of C (not C++) developed as header-only libraries, which by contrast I don't think there is nearly as good reason for except for that some people are confused at how a linker works. I have seen use of that technique advocated on Hacker News much more frequently than in production.
    - forrestthewoods 7y ago
      Header only and single file are slightly different. A headery library may include many many files. A single file or single header may be “header only” or it may have an impl define. People who prefer this distribution mechanism are generally ok with 1 header plus 1 cpp. These libraries generally have no third party dependencies. Because tracking down and compiling C++ dependencies is a dumpster fire.
      - asveikau 7y ago
        Or maybe they don't actually need the dependencies. There is a style of writing code to minimize dependencies and many people value this. I would take the sqlite amalgamation as an example of good use of "few files, few dependencies". First off, it is above all a solid piece of work. It is distributed with one header file and one .c, even though it is developed as multiple files. Iirc the sqlite website cites a ~10% speed improvement or so due to the optimizer being able to do a better job across the whole library. In my opinion this is a better reason than "tracking dependencies sucks" or "omg too many files".
msla 7y ago
> If you're using C++, you want speed and/or memory efficiency. Generic libraries won't give you that. The standard libraries should, in that they can have Spooky Deep Knowledge of the compiler and other standard libraries which external code won't, like how there's no way to add two ints which is faster than the standard + operator.
- jeffreygoesto 7y ago
  Well, this argument goes both ways, a generic implementation can never leverage special properties of your data. See i.e. Alexandrecu's talk [0] at about 1:05ff. If as a company you have special use cases or guidelines, you may easily benefit from libraries using these properties. [0] https://youtu.be/FJJTYQYB1JQ https://youtu.be/FJJTYQYB1JQ
- danbolt 7y ago
  I think you're right that some things, such as integer addition, are quick and don't require a lot of thought, but a lot of teams leaning to C++ stems from larger-scale performance considerations that aren't one-size-fits-all. A simple example is `std::vector`. The structure is a nice resizable array, but for a long time you couldn't override the allocator and the performance of your application could be affected by heap fragmentation or even just the performance cost of heap allocations. A lot of C++ shops often wrote their own replacement containers that had a better allocation strategy. The design needs of a PlayStation 2 programmer ended up being different than an x86 desktop computer with virtual memory.

m463 7y ago

I think another possibility might be to continually "roll" new wheels into the standard library. python question: Do people re-implement a lot of the core library routines at every company? Compared to other scripting languages, I found python to have a pretty large/compatible standard library (except when they renamed the url/configparser module names)

bluGill 7y ago
Python is generally not used for the types of hard problems where a company specific library would help. When performance or code size matters you leave python for something else. Thus C++ will get libraries anytime the standard library had to make a tradeoff that isn't always right. Python by making the tradeoff for features has limited itself out of places where you would trade less features for something else. This is great for python as it wouldn't play well in the less features space anyway. I expect to see company specific libraries for rust at some point because rust can play in the same space as c++ where you might want to make a different trade off.
- fulafel 7y ago
  I think this is a one sided view of Python, even though its true that it's most often used for easy problems. Eg Dropbox and Youtube are using Python, solve hard probs, probably have proprietary libs, and care about code speed.

quicklime 7y ago

I would argue that any company with enough JavaScript developers will eventually develop JS libraries too. There's nothing that limits this to just C++. Facebook has folly but also react and a whole set of tools around it.

BoorishBears 7y ago
This is more like if every company reimplemented core-js... worth a little more examination than "large companies write libraries"
- otabdeveloper4 7y ago
  React attempts the re-implement the browser DOM API and its associated UI conventions. That's way more WTF than folly, which is basically jQuery for C++.
  - BoorishBears 7y ago
    React attempts to wrap the browser DOM API and it's conventions in a way that's (for people who use it) easier to reason about, that's kind of like saying Anvil is a WTF because it wraps Vulcan Also yeah, every reimplementing jquery would be extremely strange and mostly defeat the point of jquery... which is to not have to implement jquery's constructs in Vanilla JS
mattigames 7y ago
I don't think I agree, most don't reinvent the common parts: jQuery, lodash, angular or react
- quicklime 7y ago
  Most don't, but Facebook does have its own equivalent of jQuery, lodash and angular. A few other very large tech companies are similar. Most C++ shops don't have their own equivalent of Folly, they use Boost or Google's Abseil or something else.

notacoward 7y ago

C++ does have a standard package manager. It's the system package manager, instead of a language-specific one. Whether that's good or bad is a matter for some debate, but it does exist.

BoorishBears 7y ago
> C++ does have a standard package manager. It's the system package manager, instead of a language-specific one. So C++ does not have a standard package manager. Or are we really going full HN and debating the meaning of the word standard? Even if we are... is there a standard system? For that standard system, is there a standard package manager?
- notacoward 7y ago
  You're the only one trying to play with definitions of "standard" here. The system package manager was the standard packaging method for extra functionality on Linux (and other) systems regardless of implementation language before perl/Python/etc. started coming up with their own. You might argue that it's a bad standard, that it doesn't work for more "nimble" languages, whatever, but it is how C++ code is supposed to be packaged and has been for a long time. What C++ doesn't have is an exclusive package manager that can't be used with other languages. Non-exclusivity doesn't make anything less standard. Quite the contrary.
  - BoorishBears 7y ago
    This is not how language works. You don't get to just slice up a sentence and then talk to the parts that suit you "C++ does not have a standard package manager." C++. The language. Does not have a standard package manager. From your own comment: > It's the system package manager, instead of a language-specific one You're literally admitting C++ does not have a package manager right there and then saying it's up to the system to fill in that gap! - This is a seriously mind-numbing conversation because all your replies make it clear you know EXACTLY what they mean, yet you're so focused on being the obligatory contrarian who has to proudly proclaim C++ has been done the way it's done and that's a fine way (and won't go so far as to say it's the correct way because deep down we all know it's not, but will always go right up against that line and pull out the "well it worked for all that C++ code out there" if you push back) and all you kids with your nimble languages can say it's bad but you just don't get it. This is why for my mental sanity I try to refrain from talking about the meta situation of C++. The language, not the system. To be clear.

Rexxar 7y ago

Maybe it's because the language give you all the tools to do it without any performance penalty. This allow you to have a custom library that is fit to your needs instead of a standard library that is globally good but obviously not optimal in all situations.

doctorsher 7y ago

It may not be "standard", but Conan is a C++ package manager which IMHO is quite nice to work with. Not affiliated in any way.

asveikau 7y ago

I feel a bit like there is some kind of programming totalitarian personality that wants there ever to always to be one thing. There are so many build systems in C and C++ because for each of those, someone finds something to be inadequate and has something else that works for them. Just like there is no standard for sizeof(int) or whatever, because it started with one size on one CPU and somebody brought it to a different CPU where another size made better sense. Today you can usually guess that it's 32 bits, but there are domains where it's not. These languages are meant to not impose a lot on the implementer or practitioner. Having the standard specify that every build needs to potentially pull down a bunch of crap from github or wherever else is going to be really annoying to a lot of people. It is a misguided suggestion. I think it mostly comes from people not working in the language, or unfamiliar with code bases that are working well as-is.

antoineMoPa 7y ago
I said there should be a standard package manager, this does not mean that it has to be the only one. It would just be easier for everyone if there was a widely adopted way to package, install and update stuff, like most modern languages.
- fit2rule 7y ago
  There is such a thing for C/C++ devs: Git. This works so well you may have hardly even noticed its so widespread as a solution to the problems you describe.
msla 7y ago
> Just like there is no standard for sizeof(int) or whatever, because it started with one size on one CPU and somebody brought it to a different CPU where another size made better sense. Today you can usually guess that it's 32 bits, but there are domains where it's not. This is different: C has to be implemented efficiently on a wide range of hardware, almost without regard for how good of a fit that hardware is for C or any modern language. Machines with 36-bit integers and 18-bit pointers? They got C compilers. Machines with no native notion of byte addressability? Plenty of C compilers for those things. Machines with application-visible segmentation? Of course! Those machines were quite popular for a while. Therefore, the C programming language has to at least try to make it possible for portable programs to exist. That's the implied contract of the C standard: Code to the standard, and your programs will be compilable and runnable on every platform targeted by a conformant C compiler. So, since int is going to be a size adapted to the hardware, as required for efficiency, the programs have to know how big an int is, as required for portability. > Having the standard specify that every build needs to potentially pull down a bunch of crap from github or wherever else is going to be really annoying to a lot of people. No language standard specifies that, I'm pretty sure. The ES6 standard doesn't specify left_pad and the C++ standard doesn't specify Boost. However, the standards also don't specify things which could replace those external libraries in a portable fashion which is guaranteed to always be there. If you take something out of the standard library, it has to go somewhere; people aren't going to stop doing that thing just because the standard no longer mentions it.

ivanhoe 7y ago

And then some dude somewhere deletes from repo his lib for left padding a string, and no one in the whole Facebook can compile anything until it's resolved? There's a reason why big companies like to have a full control over their code. Also it makes licensing a lot easier and legally safer.

ccktlmazeltov 7y ago

Rust has a package manager, and yet I predict that the same thing is going to happen as the standard library is pretty thin and lacking. The reason is trust, you can't trust random third party dependencies if you're writing sensitive code, it's easier to trust a std lib OR something that pretends to replace/add to it from serious people.

skyde 7y ago
Why do you think Rust would be different from Java or C#. I believe that both Java and C# are doing a good job at sharing package using Maven and Nuget.

wrsh07 7y ago

I don't think this is a particularly interesting take. Google's utility c++ library isn't that different from eg underscore.js (or lodash) Google uses some boost code and plenty of other external libraries (I can't speak to Facebook but imagine it's similar) - I think the point is just that Facebook and Google have an enormous amount of c++ code and have thus created libraries (some of which are fundamental enough or self-contained enough to open source) This is just what happens when a bunch of engineers are all working in the same language - the utility libraries become large enough, robust enough and useful enough to open source ----- As an aside, I think the similarities between folly and absl say something more meaningful about the state of c++

skyde 7y ago

thats why Rust might win in the long run because it have a common build system and package manager