Hacker News Reader

Because in those languages:

. dependencies are carefully considered by users

. dependencies are not added recursively

. dependencies try to be dependency-free themselves to assist with the previous point

. dependencies are not blindly nor automatically updated

. dependencies solve important domain problems, they are not trivial one-line-functions

. dependencies are typically developed and tested by a known team or company, which you trust, not just someone random

. binaries can be signed

. support contracts are a thing

. etc etc etc...

What you’ve said has nothing to do with languages. Claiming X devs are better than Y devs is just your bias. Other languages can be more domain specific, have more frictions around using package management, and have less nr of developers.

I have nowhere claimed anything about devs being better/worse.

This is 100% true especially stupid libraries that are someone's class project. And JavaScript developers are so used to dependency hell that one of my developer imported 3rd party package for date formatting.

JS's built in date formatting/handling is terrible and often do what needs to be one.

MomentJS may be a giant import, but it works an it works really well.

It’s the closest thing we have to a useful standard library. Date handling in js without a library is a code smell.

I am confused, are you using MomentJS for fancy output like 3 days ago etc or for simple output like 5/31/2020? I can see how it is useful in former case but seems overkill in later case.

Safari is lacking in support (again) but we have `Intl.RelativeTimeFormat`[1]

    new Intl.RelativeTimeFormat("default").format(-3, "day")

1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Formatting is fine. Take a look at `Intl.DateTimeFormat`[1]. Then there is a proposal for `Temporal`[2] which will make handling a lot easier.

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[2]: https://github.com/tc39/proposal-temporal

This seems to be a similar situation to the Bootstrap fallacy where you use the same frameworks every time you make something in a language to make it quick and easy for developers to work on all of your company's projects by just learning one. Using the same familiar libraries is great for reducing the amount of time it'll take to train someone to work on and maintain a large portion of your company's tech.

the parent said something about problems being solved if there was a standard library, and if perhaps there were a standard library people would be willing to write more code instead of just adding another dependency.

I believe these points

dependencies are carefully considered by users dependencies try to be dependency-free themselves to assist with the previous point dependencies solve important domain problems, they are not trivial one-line-functions dependencies are typically developed and tested by a known team or company, which you trust, not just someone random

would be solved by the parent comment's proposed standard library.

True to an extent, but consider Python which has a standard library and has also seen some of these same types of security breaches.

A good standard library helps, no doubt.

However, it is not required. One of the languages mentioned was C++. That language has a tiny standard lib in comparison to Java.

So it is mainly a "cultural" thing and how projects are structured and reviewed.

C++ had a tiny standard library.

That’s why Boost exists (although much of its functionality has been subsumed into the std lib now).

Yeah, I feel like Deno will reduce dependency usage, and people will hurrah and say "look, using URIs as deps actually worked to make things easier!", when in reality the reason dependency hell freezes over is because Deno actually has an STL.

I agree. lack of standard library in Node.js means everybody has to re-invent the wheel, or find on on npm.

I believe there was a time when C++ did not yet have a standard library. But now it does. JavaScript should have a standard library, not "Deno".

The problem with adding to JS’s stdlib is that it’s interpreted. If the next ECMAScript version provides new features in the stdlib, it’ll take a while for browsers to adopt it, and during that time, you’ll need polyfills.

Compare that to a new version of C++ where you just update your compiler, and the executable runs (almost) anywhere. No polyfills to run it.

I think the problem is less that it is interpreted and more that there are many different interpreters for different platforms, all of which are competing.

Python is also interpreted, but there isn't much problem changing the stdlib because CPython runs pretty much everywhere you need it to. Sure, there are other interpreters like PyPy that also need to implement changes to the lang, but it's not a show-stopper like it is with browsers.

> If I include a 3rd party package in the JVM, I have absolutely no guarantee that it will work well, much like in Node.

In the JVM you can use the security Manager [1] and limit file access and access to similarly sensitive areas. If you want you can fully guarantee that nothing is accessed randomly.

Of course that builds on the JVM not having a zero-day bug.

[1] https://en.wikipedia.org/wiki/Java_security

There are all kinds of things NPM users can do to mitigate security problems. The only interesting question is what the default is.

I remember 10 years ago (?) people were already complaining about how crazy installing some random packages via pip is instead of installing them via distro's package manager repo. The packages from distro's repo might be out of date but at least someone already vetted them they said. If someone with a time machine go back and tell them what we'll do with npm and docker today they'll probably quit programming on the spot.

I'm not too sure, but in Java, you depend on specific versions and the packages are signed. And most company have an internal repo they work off on, in case the public repo is having downtime or the package gets removed from it. Also deployments don't make use of dependencies, a single uberjar bundles it all up.

Was this all true of NPM as well?

> Also deployments don't make use of dependencies, a single uberjar bundles it all up.

That's not actually completely right... there are problems with deploying a single jar. With Java 9 modules, you're actually throwing away module encapsulation if you deploy a uberjar. The current state-of-the-art is to deploy the whole app + the JVM in a jlink image, which requires no uber jar.