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]

#101

Post by twic » Sun, Mar 03, 2019, 5:42 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.

How much is that actually necessary these days? I remember spending ages tweaking flags in the 1.4 - 1.6 years. But there have increasingly been sensible defaults with broad applicability. Now that G1 is both default and usable, even more so.

As i've moved onto 11, i've slashed our apps' JAVA_OPTS down to almost nothing - max heap size, some GC logging flags, that's it.

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

#102

Post by pjmlp » Sun, Mar 03, 2019, 5:42 PM UTC

tyingq wrote: post #89

CamouflagedKiwi wrote: post #83

Earlier quoted context omitted.

> Imagine the K8S team porting from Go to some other language for similar reasons. k8s was originally written in Java, so they have already done this once.

I didn't know that, but it makes it a more interesting comparison. I imagine at least part of rewriting it in Go was to "eat your own dogfood".

Actually it was more like "new team got in charge" actually.

There is a FOSDEM 2019 talk about it.

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

#103

Post by ksec » Sun, Mar 03, 2019, 5:42 PM UTC

twiss wrote: post #23

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…

They also state that writing the service in Node took them an hour, two days for Go, and a week for Rust. Even taking into account their unfamiliarity with the language, it's probably fair to say that when switching to Rust, you'll usually spend more time writing and less time debugging. Whether that trade-off is worth it depends on the project.

>They also state that writing the service in Node took them an hour, two days for Go, and a week for Rust.

>At npm, the usual experience of deploying a JavaScript service to production was that the service would need extensive monitoring for errors and excessive resource usage necessitating debugging and restarts.

But if you factor in over the life time of the program, Where Node saves you a week times at the initial implementation and you paid back in extensive monitoring, it is probably safe to say Rust's TCO is much lower.

Not Sure how Rust will flare against Go. But I think there is a high probability that Rust is better in the longer run.

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

#104

Post by 0815test » Sun, Mar 03, 2019, 5:43 PM UTC

Quenty wrote: post #92

tyingq wrote: post #80

Earlier quoted context omitted.

From the paper it appears to be an authorization service that decides what rights a particular user has. Not a webserver or CDN. It mentions it being CPU bound, though it isn't clear to me why it would be, or why JS wouldn't work well enough for that.

The paper makes it clear they were evaluating languages based upon efficiency. The rust implementation was more efficient than the JS one. A CPU bound service of course is bottlenecked at the CPU, and this benefits from efficiency. At scale, it makes sense to replace this with Rust. Javascript did the job, but did not provide the same efficiency as Rust.

"Javascript did the job", but not very well apparently. They specifically say that they "were able to forget about the Rust service because it caused so few operational issues". Add to that the increased CPU- and RAM-efficiency that generally comes with a rust implementation, and that rust rewrite looks like a no-brainer.

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

#105

Post by 0815test » Sun, Mar 03, 2019, 5:51 PM UTC

ksec wrote: post #103

twiss wrote: post #23

Earlier quoted context omitted.

They also state that writing the service in Node took them an hour, two days for Go, and a week for Rust. Even taking into account their unfamiliarity with the language, it's probably fair to say that when switching to Rust, you'll usually spend more time writing and less time debugging. Whether that trade-off is worth it depends on the project.

>They also state that writing the service in Node took them an hour, two days for Go, and a week for Rust. >At npm, the usual experience of deploying a JavaScript service to production was that the service would need extensive monitoring for errors and excessive resource usage necessitating debugging and restarts. But if you factor in over the life time of the program, Where Node saves you a week times at the initial…

> Not Sure how Rust will flare against Go.

I guess it will be domain dependent. Go uses a highly-developed concurrent GC, which is going to make it a lot more convenient for certain specialized workloads that involve graph-like or network-like structures. (That's the actual use case for tracing GC, after all. It's not a coincidence that garbage collection was first developed in connection with LISP. And yes, you could do the same kind of thing in Rust by using an ECS pattern, but it's not really idiomatic to the language.)

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

#106

Post by sctb » Sun, Mar 03, 2019, 5:52 PM UTC

Tomte wrote: post #7

Editorialized title. Don't do that.

We've updated the title from “Rust at NPM”. It's not so obvious how to extract a decent 80-character title from this one so we can cut the OP some slack.

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

#107

Post by tyingq » Sun, Mar 03, 2019, 5:53 PM UTC

pjmlp wrote: post #102

tyingq wrote: post #89

Earlier quoted context omitted.

I didn't know that, but it makes it a more interesting comparison. I imagine at least part of rewriting it in Go was to "eat your own dogfood".

Actually it was more like "new team got in charge" actually. There is a FOSDEM 2019 talk about it.

Thanks! The talk:

"The clusterfuck hidden in the Kubernetes code base" https://fosdem.org/2019/schedule/event/kubernetesclusterfuck...

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

#108

Post by icebraining » Sun, Mar 03, 2019, 5:55 PM UTC

derefr wrote: post #72

tyingq wrote: post #15

Earlier quoted context omitted.

I just like that someone at npm would avoid something because it has lots of dependencies and overhead. The irony is strong with this one.

Not so ironic—just because a practice is common among the median engineer in an ecosystem, doesn’t mean it will be common among the most experienced engineers in that ecosystem. Node gets a bad rap mostly for the fact that it has tons and tons of inexperienced engineers using it (probably as one of their first programming languages.) Same reason PHP got a bad rap back when. You can build solid software in both, by fi…

We're not talking about average JS developers, we're talking about the NPM maintainers.

EDIT: I did miss that. Sorry for the noise.

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

#109

Post by paulddraper » Sun, Mar 03, 2019, 5: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…

Yeah, "npmjs.com" would have been more enlightening.

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

#110

Post by breatheoften » Sun, Mar 03, 2019, 5:56 PM UTC

steveklabnik wrote: post #47

Hey folks! This is part of our whitepaper series. This means that the audience is CTOs of larger organizations, and so the tone and content are geared for that, more than HN. Please keep that in mind!

Are CTO's of largish organizations still not part of the hacker news audience ...? That seems a bit of a damning statement to be about the population of CTO's ...