[vinceguidry]

Honestly speaking, nobody should be surprised by this. Javascript on the server is a daft pursuit, and shops that rely on it are continuously rolling the dice on their uptime anyway. Anyone can release a NodeJS package, and anyone can pick it up as a dependency.

Which is nominally true for Java. But Java enjoys the advantage of maturity. These things are supposed to have been foreseen. Java projects have a lot more resources thrown at them by their orgs, and there is a great deal of talent out there making sure all of this stuff is reliable.

This... caught that whole ecosystem off guard. Javascript devs have to always be on guard, because Javascript is the wild west. Nobody blissfully using and loving Javascript really understands why Javascript has so much trouble coming up with a standard library, but anyone who gets deep enough into Java understands very painfully why you just can't rely on it like you can Java.

Nobody starts asking sober, realistic questions when Javascript breaks because Javascript is always breaking.

[btown]

There are different times, though. If you're going to roll a service in server-side Javascript at a large organization nowadays, it'll be tested to high heaven with modern CI/CD and rolling deploys, and this mitigates the fragility of applying security (or any other) updates significantly.

With Java, though, a lot of the services in production were made before this maturity was standard. There's a vast amount of software out there that's insufficiently tested and documented, some of which has dependencies as jar files included directly in the filesystem, and the relative stability of the Java library ecosystem led to a feeling that this was acceptable. It's difficult to even detect vulnerable services, much less upgrade them and trust CI to have your back. The reason this CVE is insidious is because it uniquely affects legacy software, often many layers removed from web interfaces, that was thought to be battle-tested.

[breakfastduck]

Absolutely awful attitude to have. Javascript is not always breaking. Blaming failures of libraries on the language itself is ridiculous. Literally JS on the server is no more vulnerable to downtime than other langs.

Which is why its just a stupid to be angry with java regarding this.

[vinceguidry]

Get far enough in your career and you realize ecosystems and history, and yes, language dynamics, matter. Javascript never had a module management system. It never had anything close to a strong type system. (at least python and ruby have strong type systems) All these things have to be grafted onto the language later and if you can understand the tyranny backwards-compatibility places a language under, you can understand the plight of NodeJS.

Don't get me wrong, NodeJS is improving... by implementing Ruby features.

[breakfastduck]

> It never had anything close to a strong type system

Well yeah. It never claimed to have one.

You're blaming an ecosystem for being unstable, which while I agree, ultimately has nothing to do with the lang itself.

The fact we're discussing the fact one of the most simple libs of a language (logging to the console) can have such a widely felt exploit in such a 'mature' lang makes you're entire point very ironic.

[vinceguidry]

> You're blaming an ecosystem for being unstable, which while I agree, ultimately has nothing to do with the lang itself.

It has everything to do with the language. With no built-in module support (until recently!) and a weak type system, it's virtually impossible for Javascript to get anywhere near the stability of Java.

> makes you're entire point very ironic.

OP made an observation that we're having this conversation for this particular Java vuln but Javascript breakage never provokes anything like this. I don't understand where the ironing is. <insert-Princess-Bride-gif>