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]

#71

Post by twiss » Sun, Mar 03, 2019, 5:00 PM UTC

platz wrote: post #46

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.

> about a week to get up to speed in the language

> about a week to get up to speed in the language and implement the program

is the actual quote.

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

#72

Post by derefr » Sun, Mar 03, 2019, 5:00 PM UTC

tyingq wrote: post #15

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 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 finding and absorbing engineering best-practices from people who have already had hard-fought battles to learn them; but an engineer will have to be burned at least once on building/scaling+SLAing something before they start looking for those. You might say that the Node ecosystem has a lot of programmers that are “engineering virgins”—they’ve never been forced to contend with the real problems of engineering software. But they’d be “engineering virgins” no matter what language they’re using; that’s not an indictment of the language, just a consequence of its popularity and approachability.

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

#73

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

sheeshkebab wrote: post #16

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…

Deploying a service written in any language into production environment at scale of npmjs is far from straightforward. 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.

You've identified the problem, but I think you're wrong about the cause. It's not internet centralization that's the problem, it's the mundane fact that JavaScript does not have a large standard library. And JavaScript absolutely should have a large standard library, but it's not clear what organization would have the motivation to implement, support, and promote one. It's not impossible that a community-driven effort could accomplish the same thing, but nobody seems to be working on it.

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

#74

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

mlthoughts2018 wrote: post #65

Ygg2 wrote: post #41

Earlier quoted context omitted.

> 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, wh…

Did you mean to reply to another comment? Because you're not addressing parent's point about the sordid history of non-memory safe codebases. Replying to everybody who replied to your comment is pointless if you don't take the time to read and process the replies.

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

#75

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

oweiler wrote: post #42

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…

Also with GraalVM you may get away with building a native image which doesn't require a JVM at all.

That is not the only option, though.

Enterprises that care about AOT Java have been using them almost since Java exists.

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

#76

Post by gameswithgo » Sun, Mar 03, 2019, 5:04 PM UTC

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…

maybe it is possible that some languages are actually generally worse for some domains? there isn’t any physical law that prevents one from making a language that ends up not being a useful tool in any toolbox. java might fit that category today, now that the jvm can be leveraged with kotlin, clojure, and scala... and that .net core usually performa better than the jvm

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

#77

Post by johannes1234321 » Sun, Mar 03, 2019, 5:06 PM UTC

austincheney wrote: post #48

tyingq wrote: post #44

Earlier quoted context omitted.

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.

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 their monitoring infrastructure. No damning their either.

However their company's purpose is to push Javascript and they are saying "operating JavaScript is hard, doing this in Rust is easy" which directly goes against their business.

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

#78

Post by steveklabnik » Sun, Mar 03, 2019, 5:06 PM UTC

wayneftw wrote: post #69

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

This paper is written about the experiences of the organization that distributes those millions of packages. Those same people that have written so much important JavaScript their tool gets distributed with node itself.

What kind of load do your node services get? I’d be willing to bet the npm registry has more. That plays into this kind of thing.

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

#79

Post by bdavisx » Sun, Mar 03, 2019, 5:07 PM UTC

oconnor663 wrote: post #52

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.

On the other hand, NPM itself kind of paved the way for ecosystems with tons of dependencies, managed and versioned with a single tool. Installing system software like the JVM is more old school.

You don't have to install a JVM, you can bundle it with a distribution as well.

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

#80

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

derefr wrote: post #67

tyingq wrote: post #44

Earlier quoted context omitted.

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 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.