Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

The language is nuts. It’s true what they say cargo is even better than the language, it’s just so easy to add packages to your project or to split your project into packages.

Cargo is an amazing investment as this will help people write non duplicated code. Like how many string implementations are there across c code bases. Each c project has so much code that’s the most boring, repetitive shit you can imagine. Cargo let’s you concentrate on writing your code without hassle.

I have experience with a lot of package managers, gems, go, cocoapods, sbt, cabal, pip, spm, npm, you name it but cargo is on a different plane of existence. Cargo makes the whole internet your standard library.

I also like cargo workspaces. Modern development needs a workflow where you pull in a dependency, and work on it in tandem with your code. Achieving a good workflow for this is surprisingly hard.

New java versions do break existing libraries or apps, and need to be tested thoroughly. When the company hasn't budgeted for that expense, it becomes difficult to update.

Often an architect or software team will insist on using the Oracle JVM rather than the included openjvm. That adds extra steps to download, store as an artifact, distribute, verify, etc etc.

The people who wrote the build pipeline have since been laid off, and an updated set of libraries requires a lot of work to trace back through poorly documented and understood code to make changes.

(Not to disagree with you here, it's more that I'm trying to illustrate how, with poor foresight, Java dependencies can get difficult to manage)

I think the satire here is that internet got so centralized lately that even a simple piece of code in JavaScript requires such a huge behemoth of an org running and maintaining all this monstrous infrastructure.

To me this reads like someone has a chip on their shoulder to demand that Rust be viewed as generally superior instead of merely being another tool in the toolbox that has different trade-off properties.

Referring to deploying the JVM as “operational complexity” or referring to C or C++ as “unsafe” both strike me as insecure, defensive attitudes.

Rather, you pay a trade-off of deploying the JVM in order to gain access to language features, stability, maturity, greater coverage of third-party packages. When that trade-off is worth it for some reason, such as language standardization, you happen to already have many expert Java engineers on the team, or the library you need is not readily available in other languages, then you do it. But you would never start out in a vacuum where the mere fact of deploying the JVM is “operational complexity.” Complexity in comparison to what?

It’s the same with C or C++. These languages support a type of low-level memory and data model that is permissive in ways that can lead to errors if not used properly. So you’ll ask: do I know how to properly use them for my particular use case? If not, then you might use a different language that is less permissive because you don’t need the permissiveness.

But that is totally different fromthe language being “unsafe.” Safety is a property of a program, not a language. A language can offer different levels of tooling to control safety or conversely to let the programmer be free to make safety permissiveness trade-offs on their own, and each way of doing things will have use cases it’s good at or use cases it’s bad at.

I do not know if Rust was a good choice or a bad choice for this targeted npm optimization. I assume the author knows the relevant trade-offs and why.

Regardless though, these feel like non-sequitur, pejorative pot shots to characterize Java, C or C++ in some type generic bad light, as if those tools are a priori conceptually bad, which is a silly point of view.