1. 40
  1. 7

    In short, I think it’s become entirely too easy for people using certain programming languages to use libraries from the wide world of clowns that is the Internet.

    YES. People complain about distro packaging being too slow-moving, and while that can indeed be problematic, it also provides curation, and there is value in that.

    I’ve started toying with rust recently. On the whole I like the language, and there’s a lot of useful stuff available in the crates ecosystem. But I really wish the stdlib were more batteries-included (no rand()? seriously?) so I didn’t have to wade into the murky territory of trying to judge the relative quality/stability/maturity levels of third-party crates so often.

    1. 8

      Entertainingly, C/POSIX’s rand() is a pretty good example of something, from a stdlib author’s perspective, why you really might not want somethinv in the standard library. Or at least, you don’t want its algorithm standardized… but different algorithms may have different seeding requirements, and different properties, so you end up with the possibility of needing to break standard API’s, or add new ones and deprecating old broken ones as you go. Or you end up with prolific nonstandard variants anyway, at which point, why is it in the stdlib? It just becomes a land-mine for new users to step on.

      None of this takes away from your point, which is very valid, I was just entertained you chose such a perfect counter-example. :D

      1. 2

        Or, since these problems are well-known by now, you do like Swift’s random(in:using:), which can be fed with any RandomNumberGenerator you can come up with.

        Avoiding doing anything because prior art is not good enough is easy for the implementor, but not for anyone else.


        1. 2

          Yeah, I know rand() has some nontrivial aspects of its design & implementation (and I certainly didn’t mean that as advocating emulating the C API), but I think there’s enough other prior PRNG API art out there to look at and learn from that it still strikes me as a pretty glaring omission. Date/time handling is in a very similar space – yes, there’s a high ratio of intrinsic complexity to superficial simplicity, but to not even try and just punt it completely to third-party libs is…pretty disappointing.

        2. 3

          That’s one of my greatest complains with Rust as well. Unfortunately, it’s even worse than rand(). Asynchronous I/O, which is needed by most non-trivial projects is also not standardized. Instead we have hundreds of reinventions of the same wheel, which leads to a lot of incompatibilities when you start to use heaver libraries.

          1. 3

            … so I didn’t have to wade into the murky territory of trying to judge the relative quality/stability/maturity levels of third-party crates so often.

            After a while you know which crates you trust for various tasks, or even which crate authors you like. But that’s an obstacle in getting into knowing a new language for sure.

            There’s also the cargo crev effort https://web.crev.dev/rust-reviews/ – i’m in two minds about it. Once you get a “review” there, it might be negative and talk about problems that are not present anymore. It also focuses a bit too much on “unsafe”.

          2. 7

            There are valid concerns, but I don’t see how merely making dependencies more painful to use solves anything. It’s a problem of curation, not access.

            Not having easy-to-use package manager won’t make library authors write higher-quality better-tested code. You’ll just have a smaller ecosystem, with fewer users, fewer libraries, but same clowns.

            I think solutions should focus on helping people write better code in the first place, users to find quality libraries, and making upstreaming/patching/forking easier.

            1. 4

              I agree…but at the same time isn’t conventional wisdom usually to let the library authors deal with something because they have more time/use cases/expertise/community bug reports/wisdom to Do It Right? At some point you end up with a bunch of crappy internal tools that cover your specific use cases tolerably-but-not-perfectly and a really bad case of NIH Syndrome

              1. 3

                It’s also possible that if adding a random library were more difficult, people would just copy chunks of code from the random library instead, and still won’t take the time to understand it and fix it instead of working around it. At least if it’s easy to add a library bugs might get fixed upstream.

                1. 5

                  Copy chunks from a random library? Nahhhhhh, that would never happen. Who would do that? :P

                  The flip side is that if there’s a bug in these copy-pasta libraries, it’s potentially more evident to the downstream maintainer and they might be more motivated to fix it, since it’s part of their program and they don’t have to cooperate with anyone else to get it done. I’m not sure one model is better than the other though.

                  1. 1

                    it’s potentially more evident to the downstream maintainer and they might be more motivated to fix it, since it’s part of their program

                    Especially with legacy C++, where the simplest way to include a library was to copy it into your source tree, there are lots of cases where the library source code is technically under downstream control, but in reality no-one has looked beyond its external API, so they’re just as likely to apply an external bodge as they are to study the library source code, find the real issue and fix it properly.

              2. 1

                I don’t get it. If there’s a problem with a library, why not fix it and upstream it? Most library authors are super happy about getting a pull request that improves things.

                I have not have had a single PR denied that I opened on libraries and even opinionated frameworks to fix stuff or add small features. I’m just a single data point of course.

                So let’s assume a case where submitting a fix does not work out: one can always fall back to reinventing the wheel in one’s code base, as suggested by the article. And I’ve seen plenty of that, but please, just stop. Chances are good that my homebrewed code will be much worse than any specialized library. And I know the same is true for the code of my coworkers. If anything, we need to stop reinventing the wheel so much and reuse and support more of the open source code out there, we would all be better off.

                1. 3

                  Reasoning linked in the article.

                  1. 2

                    For the record, the argument is that certain communities are so toxic/annoying/irresponsible/whatever, that getting your patch accepted is difficult and you’d rather not deal with them. But it’s typically hard to replace a dependency further down a tree by your own (fixed) version. If important, one could keep a private fork of the dependency tree instead. And possibly share patches of that private fork amongst other intimi (Fight Club-style). But this does not directly contribute to the public community.

                    My own opinion is along similar lines: the social signalling function (e.g. think of employment prospects by showing personal contributions to open source projects) could compromise quality on the long run. The original post complaints about potholes, but this might also be influenced by the social signalling function. As people are motivated to publish and promote their code (potentially by getting awarded social status, as is gameified by social networks such as GitHub), the issue of quality may be of lesser concern. And as long as the quality of software remains low, a piece of software will not be (re)used in the long run.

                    1. 2

                      Having a hard time to follow this argument, probably because I’m lacking the context. I understand the argument that there are certain communities one would want to avoid. If the majority of software in a chosen ecosystem are created by such communities, I feel sorry for that person, but can assure that there are more positive/fun/professional ecosystems out there, and hope that they have one day the opportunity to be part of one of those.

                  2. 2

                    If there’s a problem with a library, why not fix it and upstream it?

                    Time. One reason why people use libraries and frameworks in the first place is so that they don’t have to understand a specific area: they can delegate that task to a (hopefully competent) third party. To study the library source code, find the problem, develop a solution, tidy up the solution, ensure that the solution works for all possible use cases supported by the library not just you own use case, and submit the fix, can take considerably more time than a quick bodge along the lines of “if it fails try again” or “if it fails, carry on regardless”. Many workplaces still don’t allow their engineers the time required to fix things properly and upstream the fixes.