Maybe not to this extend, but if X (where X is whatever you are thinking about) had similar amount of people using it (especially junior people) this would happen there as well.
Other languages don't publish/import packages that are one line of code. I have never seen an issue like this with any other language that I've worked with.
Any sane developer that needed a one-liner like this would just manually implement it.
Not to mention that these sorts of functions are unnecessary in languages with a good stdlib or statically typed languages like rust, etc.
Know what happens every time people like you say this here on HN? They post the one-liner they would have manually implemented in their code base and it's wrong. The one that comes to mind is the "is-negative-number" package. Yes, the geniuses of Hacker News, after finding out there was an npm package for determining whether something was a negative number, could not correctly implement that function.
You and everyone here are not as clever as you think you are. This is why people prefer known-good implementations. The maintainer here did a bad release, big fucking deal.
As a stretch target: it's a bad idea to create demons out of an assortment of posts you randomly saw on HN. This site gets 3M posts a year. You can find basically anything in there.
What happens is that we each have pre-existing images that bug us (e.g. for example, people who overrate their own genius) and as we move around in the statistical cloud, random bits of whatever we run into stick to the pre-existing image and give it form. Poof, you have a demon—but actually it just became visible. Readers with other images see other demons and arrive at other generalizations. It's not good discussion because it's really about one thing but we make it about another, and comments that are skewed in that way limit their own interestingness. (I definitely don't mean to pick on you personally. We all do this.)
You may be shocked to find that there are very novice developers as well as those with 20+ years of experience who frequent HN. Using a few poorly written comments is a strawman, unless the comments you're referring to are written by the same people you're addressing here.
> Maybe its a failure of the language when it takes a third party package to determine if a number is greater than or less than zero?
It's not a failure of the language. Javascript has comparison operators like every other language, it's entirely possible to determine if a number is greater than or less than zero without importing a third-party package.
What it is is a failure of modern JS development culture, because apparently it's anathema to even write a simple expression on your own rather than import a dependency tree of arbitrary depth and complexity and call a function that does the same thing.
Their code would have been wrong even in strongly typed languages because it considered 0 to be a negative number. What language prevents you from making that mistake?
As opposed to blindly trusting and adding a dependency for a random library with a one liner?
I don't think the "don't roll your own crypto" argument really applies here. Of course we can come up with hypothetical situations where developers are incompetent or don't test their code at all. This includes armchair analysis for a post on HN, by non-javascript developers.
I would argue that it's still better than adding a dependency. Heck, you could even copy/paste the correct code.
I know I'm not a perfect programmer, so important functionality like this gets unit tested as necessary. :-)
A package with over 11 million weekly installs vs. a brand new implementation by a coworker, when I might not necessarily be around for the code review? Absolutely. I would blindly trust the package 100% of the time. Zero hesitation.
This happens because libraries installed by create-react-app depend on many other libraries (1026 transitive dependencies as of today).
As a comparison, Django, a large Python web framework, has only three dependencies (pytz, sqlparse, and asgiref), which don't have dependencies themselves
Perhaps, but I think the JS ecosystem encourages dependency explosion like no other. Looking at a 6 or 7 year old lazily written Rails app, with a lot of functionality written throughout the years, I see about 200 gems. Creating an empty app with create-react-app, it has about 1000 packages.
You can't use the very latest version of any software in Debian at all without adding a custom repository, at which point you have the same issue. So the comparison is not apples to apples.
You can use Debian Unstable, or maybe just use stable and reliable dependencies so that your software is also stable and reliable. That would require putting in some effort, though, and we can't be having that, can we?
The "slow and steady" approach works well for mature or stagnant ecosystems, but only when the packages are small enough that distribution developers can reasonably backport security fixes. That clearly doesn't work with big programs like Chrome and Firefox, so they have to resort to shipping the latest ESR version.
Writing JavaScript on Debian is practically impossible without sidestepping the package manager in some way. In a lot of cases, the hacks you have to do to run up-to-date software on a distro like Debian decrease reliability significantly.
You can do that with NPM if you pin your dependencies to exact versions, which is the same solution that you would use for any other package manager, and basically what Debian and other Linux distros do for you. I don't know why you think this problem is somehow unique to NPM or the JavaScript ecosystem.
And yet, somehow Debian isn't in the new every few months. There's a fundamental difference in culture, for one. But the fundamental difference in approach is there, too. Debian packages are vetted. npm packages are not.
How about a rolling release like openSUSE tumbleweed then? I have been using it for years, I generally update once a week and I have never broken my system due to an update. Never.
All of this is telling users how to avoid breaking Debian, and mistakes that they ought to avoid. This isn't Debian being broken and the users being collateral damage. This isn't a symptom of the very Debian ecosystem itself being fundamentally broken.
Other languages don't publish/import packages that are one line of code. I have never seen an issue like this with any other language that I've worked with.
Any sane developer that needed a one-liner like this would just manually implement it.
Not to mention that these sorts of functions are unnecessary in languages with a good stdlib or statically typed languages like rust, etc.