5 ms·

> Imo the middle ground here is that this is a common enough operation that it should be in your language's standard library, see e.g. [0][1]. Is it, though?

by fivea 5y ago

> Imo the middle ground here is that this is a common enough operation that it should be in your language's standard library, see e.g. [0][1]. Is it, though? I mean, C is around for around half a century, and C is perhaps the primary language in the FLOSS universe. Still, why is there no widely adopted idempotent directory tree creation library?

mgaunard 5y ago
Because C stopped evolving long ago, in spite of the recent C standards that have more to do with a reanimated zombie than anything else. In C++ that functionality is indeed part of the standard library.
- fivea 5y ago
  > Because C stopped evolving long ago (...) That excuse isn't credible. I mean, I asked about a libraries that handled that usecase, not a standard library. If there was demand for that use case, and that demand popped up so often that it justified the adoption of a de-facto standard, why isn't there any third-party library specialized in that usecase? I mean, putting together a library takes far less work than presenting a proposal to the C standardization committee, which is open to proposals. So, why isn't there one? Might it be that there is actually no relevant demand for it?
  - mgaunard 5y ago
    How would such a trivial library achieve popularity? It would have to be part of a larger framework. Anyway I just checked and Glib does seem to have it for example.
    - fivea 5y ago
      > How would such a trivial library achieve popularity? There is no size limit on how many features could ship with a library. In fact, we live in an age where packages like rimraff report around 50 million downloads per week. But the original question, and the point it made,still stand: why isn't there such a library to provide such a feature? Might it be that you're overblowing it's demand and usefulness? Perhaps there is no such thing in the standard library because no one bothers with it, or feels it's missing?
      - unionpivo 5y ago
        Libraries are a pain in C. So most C programs use less of them, than if you are writing js
        fivea 5y ago
        > Libraries are a pain in C. They really aren't. At all. What exactly are the pain points you experienced with C libraries? > So most C programs use less of them This assertion doesn't hold any water. In all the years I worked with C and C++ projects, not even once did I ever heard "let's not add a library, it's hard". Do you actually have a concrete, real issue in mind?
        cowsandmilk 5y ago
        > What exactly are the pain points you experienced with C libraries? 1. Varying build systems. Does the dependency use cmake? Autoconf? A shell script where you’re instructed to modify some variables specific to your system? 2. The above, but my software is shipping on Linux, windows, and Mac. What’s the best way to get this dependency compiled? Does upstream even support all these OSes? In all my years of doing C programming, I’ve never seen some add a single function library like is_even and then another like is_odd. But you do see it in languages where it is really easy to add libraries.
        convolvatron 5y ago
        in C I always end up building my own world because the default one is broken. for example null terminated strings are just really awful to work with. i'm not alone - alot of larger C projects have their own runtime, particularly memory management. another cross-cutting concern is multihreaded safety and scheduling. unless the library author broke those functions out, then I need to rehost it in my environment. so I usually end up forking any library that I want to use. this isn't all bad - I find some bugs and integrate the build. I adopt the library and develop and understanding of it sufficient to maintain it myself. contrast that to a language environment where those things - strings and threads and build are all standardized.
- vlovich123 5y ago
  Let’s not act so high and mighty. It got added in c++17 which is only four years ago and it took most implementations quite a while to implement it in the official <filesystem> location (vs as an experimental header). Oh. And we’re still lacking any kind of sockets support. There’s this thing I’m hearing about called the Internet that’s going to be big any day now and might need this.
  - fivea 5y ago
    > Oh. And we’re still lacking any kind of sockets support. There’s this thing I’m hearing about called the Internet that’s going to be big any day now and might need this. Between libcurl, POCO, or even Qt, does it matter at all that the C++ standard offers "any kind of sockets support"? Just because Java forced everything under the sun into their standard library, that does not mean that move makes any sense at all. Between Boost and Apache and POCO and others like that, it's high time we stop insisting in this nonsense.
    - vlovich123 5y ago
      That’s one position. The other is one most other languages choose which is some kind of cross platform sockets support out of the box with packages filling in more niche cases for performance or usability reasons. You could easily make the same counter argument against including <filesystem> and yet there’s very real value to having something cross platform out of the box that handles elegantly various pitfalls that people typically fall into.
      - fivea 5y ago
        > The other is one most other languages choose which is some kind of cross platform sockets support out of the box with packages filling in more niche cases for performance or usability reasons. Given that Java followed that path and already acknowledged that mistake by deprecating the original HTTP client, why do people insist in not learning lessons?
        5y ago

mgaunard 5y ago

I fail to see how "any kind of sockets support" is true, given that there is a networking TS as well as well-established networking libraries. The main reason why all these things haven't really been integrated into the main language yet is because the committee is still experimenting with various approaches to asynchronous programming and scheduling with goals of also integrating these with heterogeneous computing. Also sockets are arguably an outdated networking model anyway, so people really serious about high-performance networking will be doing their own thing regardless.

vlovich123 5y ago
I could buy that reasoning in the 90s. Heck even in 2000 after the dotcom bubble burst. I could maybe buy it in 2010 although by then networking was in no way even remotely niche. We’re now into the third decade of networking and far less important additions to the standard library have been made. A TS is almost nothing in the c++ world. Each implementation will have its own quirks and unreliable cross platform behavior if it’s even available. There are well established filesystem libraries too (heck the STL implementation is almost identical to boost for that reason to make it easier for those people to port and for the library maintainers you basically just wholesale copy an implementation or at least have a reference one to test most things against). > Also sockets are arguably an outdated networking model anyway, so people really serious about high-performance networking will be doing their own thing regardless. I’m eager to hear what you mean by this because I’m unaware of any OS APIs that do Networking in any other way. Unless you’re talking about userspace drivers or DPDK, neither of which see serious adoption outside of data centers (if even there). 99.99% of an networking code I’ve observed across mobile and cloud is socket-based.
- mgaunard 5y ago
  High-performance networking somewhat excludes mobile and cloud. Regardless, the io_uring interface, which is general-purpose and still based on file descriptors for its initialization, does go out of its way to work around some of the problems with the socket model.