Actor models don't solve the problem of getting a good-sized ecosystem going. If you have production-ready actor-model libraries for all the random things I might want to connect to, great, but I'm not currently aware of such things existing. (Maybe that's a failure of listening on my part!) If you want to develop that ecosystem, awesome, and I totally support that.
But I would much rather bring a knife to a gunfight than some totally awesome, straight-from-the-laboratory gun that's never been tested in combat.
> If you have production-ready actor-model libraries for all the random things I might want to connect to, great, but I'm not currently aware of such things existing.
If you have production-ready event loop libraries for all the random things I might want to connect to, great, but I'm not currently aware of such things existing.
Part of the problem with the Node ecosystem is that the bar for "production ready" is very, very low. For example, literally nothing in NPM is production ready where security matters, because the package system is fundamentally insecure. left-pad broke builds everywhere--what if instead of failing to download, it introduced a backdoor? And even if you assume all the randos who maintain NPM packages are trustworthy, there's no signature verification on code, so any of them could have their accounts compromised and there would be no way to tell. This is the code you want me to run on my server? Really?
Node has a large ecosystem, but the subset of Node's ecosystem which is actually quality software is quite small.
> But I would much rather bring a knife to a gunfight than some totally awesome, straight-from-the-laboratory gun that's never been tested in combat.
Me too, but I'm exceedingly surprised to hear you quote this as a positive of Node.
I am not really familiar with how to deploy Node in production, having never done so, but aren't there relatively easy ways to mirror NPM locally? Or can't you just check node_modules into version control (possibly a separate branch or something)?
Honestly if I had to deploy Node in production I'd be inclined to see if I can just use those Node libraries that are packaged for Debian. I do the same thing for deploying Python, Perl, C, etc. in production.
I phrased it that way to be polite, but if you're not interested: I know that these tools exist. I was giving you an opportunity to save face for your uneducated and factually incorrect claims. The left-pad incident broke CI tools that intentionally referenced public NPM, not competent internal deployments. It broke incompetent internal deployments, yes, but every other language ecosystem can be deployed incompetently.
If you're relying on the availability and correctness of a public service for deployments, whether or not it's signed or allows packages to be removed, you're doing it wrong. This is as true for NPM as it is for Debian.
Unless you were just outright lying, not having ever deployed Node in production isn't just being polite, it's literally admitting you have no practical knowledge of the technology you're defending.
I can see some value in the feedback of someone who has only worked with Node 3 months or so--newcomer reactions give some impression of the learning curve of the technology, which matters. But you've done what, read a blog post? Your opinion on this subject is worthless.
> I know that these tools exist.
As do I, and what's more, I've used those tools.
> I was giving you an opportunity to save face for your uneducated and factually incorrect claims.
Which ones were those exactly?
> The left-pad incident broke CI tools that intentionally referenced public NPM, not competent internal deployments. It broke incompetent internal deployments, yes, but every other language ecosystem can be deployed incompetently.
Yes, you can use NPM shrinkwrap (and I do) but let's be clear: that means you get to devote perhaps a week out of every year updating everything manually. "Competent" deployments with NPM involve enough of a pain in the ass that, after a few years of doing this, I'd actually prefer to manually import dependencies. But that's not really a viable option.
If you're going to claim this is just incompetence, I am inclined to agree with you. But that means that an inordinate portion of the Node community is incompetent, so I'm not sure this can be represented as a defense of Node.
> If you're relying on the availability and correctness of a public service for deployments, whether or not it's signed or allows packages to be removed, you're doing it wrong.
If that's the case, then I don't know of ANYONE who is using NPM correctly, because to avoid relying on whether or not things are signed, you'd have to audit literally everything pulled down by NPM, which even for simple projects can be half a million lines of code. Shrinkwrap means you only have to do it once, but that's still more time than anyone I know of has.
None of this is different in any other language, including C. If you run a C app that uses outside libraries, or a Python app that uses outside libraries, or anything else, you either devote well more than a week out of every year to updating libraries, or everything is super old and frozen and impossible to change, or everything risks breaking when you upgrade your OS distribution (or other source of packages). That's how production software works.
If you want to claim that the state-of-the-art in every single environment isn't production-ready, you're using the term "production-ready" in a very different way from its common meaning.
Can you present an ecosystem that does this better? All I've heard you claim is that Node is bad, in ways that are not specific to Node.
> None of this is different in any other language, including C.
Really? Because NPM is the only dependency system I know of that doesn't verify packages in any way.
> If you run a C app that uses outside libraries, or a Python app that uses outside libraries, or anything else, you either devote well more than a week out of every year to updating libraries, or everything is super old and frozen and impossible to change, or everything risks breaking when you upgrade your OS distribution (or other source of packages).
This hasn't been my experience. Unlike the Node community, the C community tends to feel strongly about reverse compatibility. The Python community has become a bit more diluted in recent years, but as long as you stick with mature libraries, upgrades are usually no more than updating some version numbers in the `requirements.txt` and running `pip install -r`. In cases where Python packages break dependencies, they're usually pretty decent about giving deprecation warnings.
In NPM, mature libraries break backwards compatibility without warning all the time, sometimes without even a version number change (by virtue of the dependency's dependencies).
Can you point me to an example of a mature library in Python breaking like Babel did when left-pad happened?
> Can you present an ecosystem that does this better? All I've heard you claim is that Node is bad, in ways that are not specific to Node.
The ways I mentioned are absolutely specific to Node.
> Really? Because NPM is the only dependency system I know of that doesn't verify packages in any way.
npm verifies the SSL cert on its connection to the registry. pip does the same thing. Neither verifies signatures on the packages, or anything else.
Both of which are better than C build scripts that involve downloading tarballs from SourceForge and running `make install`.
> This hasn't been my experience.
Then you're not running C in production, sorry. Or you're ignoring the friendly build engineers and distro packagers (like myself) who spend their days solving these issues so you don't have to notice. Which is great, we solve these problems so you don't have to, but you really need to defer to the people with expertise.
> Can you point me to an example of a mature library in Python breaking like Babel did when left-pad happened?
Sure. Babel didn't break when left-pad happened. A certain way of installing Babel did. I have no idea how you keep conflating a method of installing packages (that isn't even what serious production users use) with code. So, "all of them."
I can give you countless examples of mature libraries and software packages in C, Python, or many other languages where `./build.sh` or equivalent, that wgets some crap from SourceForge, stopped working in the same way. But if you're doing `./build.sh` as part of your regular production workflow, you know that it's going to break and that you have better options.
> Both of which are better than C build scripts that involve downloading tarballs from SourceForge and running `make install`.
True, but I thought you were the one who wanted to limit our conversation to competent installations?
> Sure. Babel didn't break when left-pad happened. A certain way of installing Babel did. I have no idea how you keep conflating a method of installing packages (that isn't even what serious production users use) with code. So, "all of them."
Really? So how do you install Babel the first time in order to shrinkwrap it?
> I can give you countless examples of mature libraries and software packages in C, Python, or many other languages where `./build.sh` or equivalent, that wgets some crap from SourceForge, stopped working in the same way.
I'm not sure what this has to do with anything. Yes, you may sign your uploads. Nobody verifies them on download.
Since you seem to be a fan of Google, try Googling 'pip signature verification' and reading the results. Here's one place to start: https://github.com/pypa/twine/issues/157
> Really? So how do you install Babel the first time in order to shrinkwrap it?
The same way you install anything else from any other ecosystem? The packages have to be up and online when you initially retrieve them, yes. I have no idea how you think that's NPM-specific. If you would like to download some code, you have to have somewhere to download it from.
But I would much rather bring a knife to a gunfight than some totally awesome, straight-from-the-laboratory gun that's never been tested in combat.