It has long been believed that the tiny focus area of the C ++ library is something bad that holds the language back. Most “modern” languages come with large framework libraries, which include networking, graphics, and JSON. In contrast, if you want to do one of these in C ++, you a) get nothing by default, and b) are overloaded with a choice of third-party libraries that you usually cannot properly evaluate and select.
This is how this side of opinion goes.
Of course, there are other people who think that it should be so. However, standardization is hard work, and while in languages such as Java and C # and Go, there are large companies that can invest in developing a huge library, C ++ does not have such a workforce, and most people who spend time standardizing C ++ are more interested in the main aspects of programming: data structures, concurrency, language evolution (concepts, ranges, modules ...).
So, it’s not that people tend to oppose a larger library, but for many this is not a priority. But if good ideas come, they have a good chance to consider. And large library components, such as networking, will not be included in the standard library in any case, but rather in an independent technical specification that allows you to determine whether this idea is useful, popular and correct. Only if TS is widely used and receives a lot of positive feedback will there be possible future work to incorporate it into IP.
(You may have noticed similar attempts to create technical specifications for file systems and graphics.)
Kerrek SB
source share