Live data from Hacker News

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

rust-lang.org

81–90 of 307 posts

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

#81
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…

For what is worth, I'm not a Rust dev. I did wrote some code in Rust, but by that definition I'm also a Fantom dev.

I've just seen too many memory exploits in C/C++ to consider statements like "you can achieve memory safety in C/C++ if you're a True Scotsman" as anything other as logical fallacies.

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

#82

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

First point is also possible with Java.

Second point depends on the data structures being used.

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

#83
post #44

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.

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

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

#84
post #63
post #28

Earlier quoted context omitted.

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.

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.

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

#85
post #71
post #46

Earlier quoted context omitted.

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

the point is to measure at a common level of proficient across different languages. Once you are proficient and familiar with a language, then you can measure how long it takes you compared to another lang.

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

#86

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…

The article may have been hosted at rust-lang.org but it was written by people at npm which is very much a JavaScript boosting organization.

Rust definitely has some benefits as well as tradeoffs when compared to JavaScript which they discuss. Learning curve is higher but the end product is probably devoid of a number of errors and operational issues over the lifetime of the service. While in theory possible to get similar results with JavaScript the level of consistent discipline it requires is in practice impossible.

These are facts not opinions.

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

#87
post #61

Earlier quoted context omitted.

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.

You are making the parents point for them.

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

#88
post #8

Earlier quoted context omitted.

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

But having options is always good, isn't the same with compiled languages? you keep the defaults options but if you want extra performance you try different compiler flags or different compiler if the language has more then one.

Honestly I’d rather have good defaults than lots of options. If one tool meets requirements out of the box, then it’s preferable to a tool that requires a lot of tooling.

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

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

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

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

#90
post #80
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.

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