Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf] • Hacker News Board

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

#61

Post by pjmlp » Sun, Mar 03, 2019, 4:49 PM UTC

sheeshkebab wrote: post #11

javagram wrote: post #5

Title could be improved, as I was wondering if the command line tool npm had itself been rewritten. It’s actually one of npm’s web services that was rewritten. FTA: “Java was excluded from consideration because of the requirement of deploying the JVM and associated libraries along with any program to their production servers. This was an amount of operational complexity and resource overhead that was as undesirable a…

Deploying jvm app/service is now even more complex than figuring out which version of node to use to run a service. Is it supposed to be oracle java? Openjdk? Adoptopenjdk or one of a half dozen more? Which version of it? Anything to tweak in gc or startup settings for it/the version? Do we need to regression test the service on minor jdk upgrade? Is that jvm compatible with some os version we are running that has so…

It is pretty clear to any regular Java developer that bothers to keep up with the news.

Regression tests are required for any toolchain.

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

#62

Post by platz » Sun, Mar 03, 2019, 4:49 PM UTC

Jare wrote: post #54

platz wrote: post #49

Earlier quoted context omitted.

Default laziness in Haskell is not as big a problem as is made out to be. For someone like NPM though, Haskell's current GC would probably be too much of a bottleneck. Haskell's GC is tuned for lots of small garbage and does not like a large persistent working-set. But this has nothing to do with laziness.

> Default laziness in Haskell is not as big a problem as is made out to be It will take a fair amount of time to be proficient in Haskell to the point where it is not a (potential) big problem.

Honestly just using strict data structures (one StrictData pragma will do) and strict accumulators in recursive functions will get you there, it's not that hard.

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

#63

Post by pjmlp » Sun, Mar 03, 2019, 4:50 PM UTC

tyingq wrote: post #28

vbezhenar wrote: post #21

Earlier quoted context omitted.

I just unpack JDK, I have no idea what so complex about it. It was complex on Windows because I used VM to install Java and then copy folder, but they made it easier with 11.

One example might be that if you unpacked the Oracle JDK, you owe Oracle a non-trivial amount of money now.

Only if deployed in production, and there's nothing hard to understand it.

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

#64

Post by nikeee » Sun, Mar 03, 2019, 4:51 PM UTC

Anyone knows if they considered .NET Core? It has dependency management, can be deployed as a self-contained binary and is memory safe. Seems to match the requirements for me.

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

#65

Post by mlthoughts2018 » Sun, Mar 03, 2019, 4:51 PM UTC

Ygg2 wrote: post #41

mlthoughts2018 wrote: post #18

> ““Java was excluded from consideration because of the requirement of deploying the JVM and associated libraries along with any program to their production servers. This was an amount of operational complexity and resource overhead that was as undesirable as the unsafety of C or C++.” To me this reads like someone has a chip on their shoulder to demand that Rust be viewed as generally superior instead of merely bein…

> 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. To be honest, I don't think I know of single piece of C/C++ code that doesn't suffer from security exploits from "improper" memory use. Chrome does, Firefox does, Linux does. Hell car and pacemaker software suffers from exploits, most likely caused b…

This type of thinking is exactly why I stay away from the developer communities of Rust and Julia. Both communities seem to have this weird perception that their respective language categorically supersedes other tools in all use cases.

Don’t get me wrong. Rust and Julia are very cool languages with a lot of use cases where they are great choices. But the communities come off as disproportionately full of zealots, which makes me less interested to put effort into yoking real projects to either of those communities.

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

#66

Post by pjmlp » Sun, Mar 03, 2019, 4:52 PM UTC

feikname wrote: post #8

javagram wrote: post #5

Title could be improved, as I was wondering if the command line tool npm had itself been rewritten. It’s actually one of npm’s web services that was rewritten. FTA: “Java was excluded from consideration because of the requirement of deploying the JVM and associated libraries along with any program to their production servers. This was an amount of operational complexity and resource overhead that was as undesirable a…

JVM tuning (especially the GC and memory allocation scaling) can be a huge PITA.

Hardly any different that having to use VTune or perf to optimise C and C++, which require the added steps of recompiling with different flags and redemploying.

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

#67

Post by derefr » Sun, Mar 03, 2019, 4:54 PM UTC

tyingq wrote: post #44

austincheney wrote: post #39

Earlier quoted context omitted.

> This entire article is a pretty damning report on JavaScript in general How so?

A team that likely has lots of JavaScript expertise basically stated that JavaScript is unsuitable for their task. And that the operational improvement once written in Rust was notable enough to write a paper. Imagine the K8S team porting from Go to some other language for similar reasons.

Does every language have to be suitable for every task? “Operating a business-logic-embedding CDN at scale” isn’t ever something Node claimed to be capable of. I wouldn’t expect any other dynamic runtime-garbage-collected language, e.g. Ruby or Python or PHP, to be suited to that use-case either.

Use the right tool for the job. The PHP website is running PHP, but it isn’t running a web server written in PHP. Web servers are system software; PHP isn’t for writing system software. Same thing applies here. Node does fine with business logic, but isn’t really architecturally suited to serving the “data layer” when you have control/data separation.

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

#68

Post by rmrfrmrf » Sun, Mar 03, 2019, 4:55 PM UTC

javagram wrote: post #5

Title could be improved, as I was wondering if the command line tool npm had itself been rewritten. It’s actually one of npm’s web services that was rewritten. FTA: “Java was excluded from consideration because of the requirement of deploying the JVM and associated libraries along with any program to their production servers. This was an amount of operational complexity and resource overhead that was as undesirable a…

I'm not a fan of relying on distro package managers for installation of runtime dependencies on servers. Too many opportunites for variables to creep in if the version isn't locked, and then having to make sure all the package manager dependencies and config themselves. Even if you automate you're still at the mercy of the repo to have the version you need etc. and often times you need to customize the install for a highly-available and/or virtualized environment. Bad times all around.

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

#69

Post by wayneftw » Sun, Mar 03, 2019, 4:57 PM UTC

nothrabannosir wrote: post #10

This entire article is a pretty damning report on JavaScript in general, but this sentence takes the cake (emphasis mine): > The process of deploying the new Rust service was straight-forward, and soon they were able to forget about the Rust service because it caused so few operational issues. At npm, the usual experience of deploying a JavaScript service to production was that the service would need extensive monito…

Do you actually believe it and why? To me it looks like a fairly pathetic attempt to damn JavaScript but I'm not sure why anyone who has actually used JS for any length of time would be convinced of its accuracy.

The article is hosted at rust-lang.org so one would be wise to take their words with a grain of salt. And Rust isn't even a tiny fraction as popular as JavaScript and so when you use Rust you're choosing from a small set of packages written by experts and the kind of people who use languages that nobody else really uses. Meanwhile, JS has millions of packages written by everybody for various platforms (since JS can run in all sorts of environments where nobody would ever want to run Rust.)

Also there's the anecdotal, yet easily empirical evidence that just about any developer who uses JS can tell you about: I deploy new JavaScript services all the time without any of those problems.

So, I wonder if you're actually asking this question or if you have some other agenda.

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

#70

Post by steveklabnik » Sun, Mar 03, 2019, 4:58 PM UTC

nikeee wrote: post #64

Anyone knows if they considered .NET Core? It has dependency management, can be deployed as a self-contained binary and is memory safe. Seems to match the requirements for me.

https://news.ycombinator.com/item?id=19295166