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

51–60 of 307 posts

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

#51

Post by mlthoughts2018 »

tln wrote: post #31
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…

> Referring to deploying the JVM as “operational complexity” or referring to C or C++ as “unsafe” both strike me as insecure, defensive attitudes. Calling their attitudes "insecure" sounds petty to me. The engineering rationale was laid out and makes sense, especially if you apply a little charity and read that the JVM operational complexity was undesirable TO THEM. If your org has JVM deployments already with experi…

In the post it is specifically stated that Java was ruled out a priori because deploying the JVM and associated libraries is unqualified “operational complexity” that they don’t desire. They have not said why that is undesirable in a use-case specific way, only that they view it as generically undesirable.

Similarly they brush past usage of C or C++ because of “unsafety” without explaining why you could not achieve a parsimonious, safe solution in either of those languages.

Here is the quote again where all three languages are disingenuously dismissed in a manner that is clearly meant to be pejorative,

> “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++.”

Upon re-reading the article, I stand firm that my analysis is fair, that I’m not reading anything into it, and that the article needlessly tosses in malignant comments about these other languages, and that this is a clear indicator of insecurity.

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

#52

Post by oconnor663 »

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.

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.

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

#53

Post by BlackFly »

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

Just so everyone here is aware, this is by now an outdated complaint against Java.

https://vertx.io/blog/eclipse-vert-x-goes-native/

I'm choosing vertx as an example since it competes already with rust and c based applications over at https://www.techempower.com/benchmarks but you ought to be able to compile general programs ahead of time.

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

#54

Post by Jare »

platz wrote: post #49
masklinn wrote: post #45

Earlier quoted context omitted.

I would expect that to be par for the course for most languages. The more dynamic the more problematic, but it stands to reason that the less you can check for and enforce statically the more will eventually blow up at runtime. Resource usage is similar though not exactly aligned e.g. Haskell has significant ability to statically enforce invariants and handle error conditions, but the complex runtime and default lazi…

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.

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

#55

Post by mlthoughts2018 »

the_duke wrote: post #29
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…

Nothing in the article says no one should consider Java, just that they rejected it. You know nothing about their team expertise (probably very little Java background) and their deployment setup. The concerns are perfectly valid in my opionion: * JVM brings an increase in deployment complexity (version upgrades, etc) * Deploying a high-volume Java application requires experience and usually also tuning of the VM para…

I think you are only proving my point here. They have not provided any specific details about any of this, and did not elect to make a prototype implementation in Java to actually measure the costs and compare to the other solutions.

So you’re precisely right that I don’t know why they chose to dismiss Java as a candidate language. That’s my whole point.

If they aren’t going to provide evidence or more detailed explanation of why Java wouldn’t solve it well, then it seems very disingenuous that they do throw in a pejorative comment like saying Java adds unqualified operational complexity.

And the same thing for unqualified “unsafety” of C or C++. I’m willing to cut them more slack about C/C++, but still there is zero need to toss in these pot shots as if those languages are always inferior in an absolute sense (that is the only thing we can possibly think they mean, literally because they dismiss those choices out of the box with little discussion and no experimentation).

They could have just said something like this:

“We elected to create candidate implementations in node, go and rust. We did not elect to consider Java, C or C++, but would encourage others to evaluate those alternatives if they seem applicable in other use cases.”

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

#56

Post by tyingq »

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.

Npm doesn't seem to break any substantial new ground to me. Things like apt, CPAN, etc, have been around longer.

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

#58

Post by Go0the0gophers »

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.

Or thread pool size...

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

#59

Post by zukzuk »

atoav wrote: post #50
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…

Rust's package managment (cargo) is the best thing I have ever seen of it's kind. The very basic thing you can do is: cargo new funkyproject Which creates a new barebones rust project called "funkyproject". Every dependency specified in it's Cargo.toml will be automatically downloaded at build (if there is a new version). When a build is sucessful the versions of said dependency will be saved into a Cargo.lock file.…

npm (and yarn) literally does exactly all of this, via `npm init funkyproject` and `package-lock.json`.

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

#60

Post by atoav »

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.

It depends, I am over a year in Rust and it doesn't take me that much longer to write something in it than say in Python. The confidence I have that the thing I wrote is way higher in Rust and it is usually much faster.

And: it is incredible easy to build and deploy.

I think whether Rust is useful or not depends entirely on the application. If you need high confidence in what the thing is doing, it should run parallel and fast and you are familiar with the concepts Rust is using – it isn't a bad choice. For me it replaced Python in nearly every domain except one-use scripts and scientific stuff.

It can be hard for advanced programmers to abandon certain patterns they bring from other languages though. In the first months I tried too much to use OOP, which doesn't make any sense and leads to convoluted code. If you work more in a compositional and data oriented way while making use of Types and Traits, you will end up with much simpler solutions that work incredibly well.

Katherine West's RustConf 2018 Talk on ECS Systems describes this incredibly well and might be even good to watch if you are never intending to use Rust at all, because the patterns discussed are quite universal: https://www.youtube.com/watch?v=aKLntZcp27M

Post reply on HN