Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

rust-lang.org

Post reply on HN
Print view View original

91–100 of 307 posts

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

#91

Post by weberc2 »

pjmlp wrote: post #66
feikname wrote: post #8

Earlier quoted context omitted.

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.

I wouldn’t recommend C or C++, but in their defense, you don’t need to worry about tuning as soon as you do on the JVM. Many apps won’t need to bother with it at all (which is good because C/C++ programmers have all manner of other things to worry about that aren’t a concern for modern languages).

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

#92

Post by Quenty »

tyingq wrote: post #80
derefr wrote: post #67

Earlier quoted context omitted.

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 serv…

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.

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

#93

Post by brown9-2 »

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…

It reads like an innocent misperception due to inexperience with Java.

Very few people would choose to install libraries (JARs) used by their code via their OS package manager for instance.

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

#94

Post by amluto »

faitswulff wrote: post #20
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…

The whitepaper notes that almost 9 billion NPM packages are downloaded per week, so I don't see anything laughable about needing good monitoring.

Which is roughly the equivalent of every single human being downloading two npm packages per week. To me, this suggests that the real problem is that too many packages are being downloaded.

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

#95

Post by Dowwie »

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.

Once a programmer achieves a certain competency level with Rust, writing familiar workflows requires little additional effort than what is expended with a dynamic language. However, lower level Rust will demand more, regardless of proficiencies.

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

#96

Post by pjmlp »

weberc2 wrote: post #91
pjmlp wrote: post #66

Earlier quoted context omitted.

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.

I wouldn’t recommend C or C++, but in their defense, you don’t need to worry about tuning as soon as you do on the JVM. Many apps won’t need to bother with it at all (which is good because C/C++ programmers have all manner of other things to worry about that aren’t a concern for modern languages).

Me neither, I do like Rust and see its adoption at NPM as good PR for the language, however I also think that the way the decision process went wasn't free of bias.

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

#97

Post by pjmlp »

tyingq wrote: post #84
pjmlp wrote: post #63

Earlier quoted context omitted.

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

Commercial development or test use isn't free. It's only free for personal, noncommercial use. So I'd argue it isn't so easy to understand.

How it isn't? You just explained it quite well.

Not to mention that the Web is now full of discussions around this, with official posts from Oracle, Red-Hat, Amazon, IBM, Azul, Microsoft explaining how to go forward.

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

#98

Post by tyingq »

Outpox wrote: post #90
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.

Well I'd say that if it's an authorization service there will be cryptographic calculation which is "heavy" on the CPU.

I don't think that's what it does. "the authorization service that determines whether a user is allowed to, say, publish a particular package"

Also, I would assume any crypto in v8 is already written in C, with JS calling into it.

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

#99

Post by tyingq »

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.

I'm not clear on why this is particularly CPU heavy, though: "the authorization service that determines whether a user is allowed to, say, publish a particular package"

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

#100

Post by austincheney »

johannes1234321 wrote: post #77
austincheney wrote: post #48

Earlier quoted context omitted.

I guess I just don't see it. NPM is a massive infrastructure where one little piece was rewritten in Rust and then the Rust team wrote a promotional paper about it. The paper isn't bad, but it also isn't a technical white paper. I don't see how any of this is critical of JavaScript, which isn't even really discussed in the paper and still runs the rest of the infrastructure. If anything the paper is more damning of C…

> If anything the paper is more damning of C, C++ I don't see it as damning on either of these. On C++ it says "we didn't want to learn it." Which is fine. Maybe after learning they would have decided different, or not. On Java they said "we didn't want to learn how to operate it" as they feared the complexity of an Java application server for a single small service, which they can create in a way which hooks into th…

I think you and I read completely different papers. I didn’t see anything about not wanting to learn or motivations of easy.
Post reply on HN