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

231–240 of 307 posts

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

#231

Post by acdha »

simion314 wrote: post #178
weberc2 wrote: post #88

Earlier quoted context omitted.

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.

But if you do not have options then what is a "good default" , you have a default option if you have more then an option, so you prefer software with no options? Can you give examples of languages(compilers or VMs with bad defaults in your opinion?

Java by default has a hard memory limit which when hit causes services to hang in a semi-responsive state rather than exiting cleanly, requiring every user to hand-tune limits and carefully setup health checks and monitoring. Two decades in, they added a non-standard option to instead exit.

If they had instead made the default to act like almost everything else it would have worked with standard process monitors and limits with no effort required and a substantial fraction of the downtime I’ve seen for Java applications would never have happened.

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

#232

Post by paulddraper »

db48x wrote: post #227
0815test wrote: post #200

Earlier quoted context omitted.

Maybe, but you have to specifically opt-in to the nightly toolchain in order to compile something that uses it. It's not something that's included by default, or appropriate for use in production scenarios (unless you're willing to deal with the resulting breakage, of course).

Of course it's not suitable for production, but it was still quite common to look at a rust project and find that it used the nightly compiler.

It's been awhile, but if memory serves tons of stuff was using the nightly compiler.

So, yes buyer beware. But when the whole ecosystem does it...

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

#233

Post by [deleted] »

dpcx wrote: post #212
manigandham wrote: post #208

Earlier quoted context omitted.

Why is that insane? What else is supposed to happen when you install a package? EDIT: I misunderstood and thought you were talking about installing a package. If you're running `npm install` to just reinstall dependencies then yes the lockfile should not be modified. However it seems like that is indeed the case and you may be talking about a prior bug with NPM.

`npm install` is what you the developer would run when you first clone a project; it should install exactly what's in the package-lock.json file. Unfortunately, it sometimes doesn't do that.

[deleted]

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

#234

Post by tyingq »

IsaacSchlueter wrote: post #168
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 mean, we still write the overwhelming majority of our code in JavaScript. We port to Rust when CPU-heavy task becomes a bottleneck to the rest of the system. It's not as if this paper is saying (nor is it the case) that we've ported the whole registry to Rust. JS has lots of advantages we appreciate.

I'm curious why this authorization service is CPU intensive. The article says it's basically deciding if you're authorized to publish a package. It sounds like the sort of thing that would talk to a database, or a cache like redis, and therefore mostly be IO bound itself.

Is this maybe parsing data structures itself?

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

#235

Post by paulddraper »

pcwalton wrote: post #146
paulddraper wrote: post #117

Earlier quoted context omitted.

> New java versions do break existing libraries or apps Have you used the Rust compiler? My experience tells me that any Github Rust project not updated in the last two years doesn't work with my Rust compiler. Whereas Java apps written a decade ago still compile and run on OpenJDK/Oracle often with zero or near zero changes. > Often an architect or software team will insist on using the Oracle JVM rather than the in…

> My experience tells me that any Github Rust project not updated in the last two years doesn't work with my Rust compiler. Please file bugs against the Rust compiler then, because that would be a serious violation of the compatibility rules!

Unfortunately, I don't know enough to rewind history and do enough archaeology to find out whose "fault" it is.

But as a possible example, typemap [1] which is a library featured on Awesome Rust [2] ("curated list of Rust code and resources").

Project uses cargo. Has a lock file with two deps. Last code commit was May 2017. And I can't get it to compile.

[1] https://github.com/reem/rust-typemap

[2] https://github.com/rust-unofficial/awesome-rust

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

#236

Post by koyote »

ilovecaching wrote: post #111

I'd like to point out that even though it took them a week compared to an hour, a week is actually incredibly fast to learn Rust and build something useful with it. Learning C++ can take more than a month of training, and it's only because most people learn it over an entire semester at school that they learn it at all. This is also the time it takes to learn Rust, and presumably now that they've written one program,…

> I'd like to point out that even though it took them a week compared to an hour, a week is actually incredibly fast to learn Rust and build something useful with it.

I would argue that something that takes even an experienced engineer a mere hour to write is very small and has little complexity (especially if unit tests are counted towards the hour it took them to re-write it). This means it's difficult to gauge how much Rust was 'learned' during that week.

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

#237

Post by Twirrim »

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.

> Whether that trade-off is worth it depends on the project.

Sure, but when you consider the drastically reduced operational cost that they're talking about there... that week is absolutely peanuts in comparison, and that was also a week including getting to grips with the language sufficient to produce the component. You really don't want to have to pay attention to production. You want to be able to concentrate on getting stuff done, not losing time keeping what you've already got just ticking along.

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

#238

Post by cryptica »

The idea that some programming languages can solve scalability issues is a myth. A language cannot solve scalability issues; all they can do is push the needle a tiny little bit further in terms of performance but this is completely meaningless.

Scalability is an architectural concern which cannot be ignored by system developers. This is because scalability is not about speed or performance, it's all about figuring out which workloads can be split up and executed in parallel; in order to do this, you need to understand the real-world problem which the software is trying to solve; this is not something that you can delegate to a compiler.

The best that a language can offer in terms of scalability is to make it easier to reason about parallel workloads and make the difference between serial and parallel workloads as explicit as possible. Whenever a language tries to hide the complexity of parallelization behind thread pools, they're not solving any real scalability issue; they're just delaying them some more.

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

#239

Post by aboutruby »

the_duke wrote: post #2

A better title would be the subtitle of the article: "The npm Registry uses Rust for its CPU-bound bottlenecks". Note that only one service (authentication) was rewritten from node to Rust.

Or title could use "npm, Inc" as it's referring to the organization

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

#240

Post by kbenson »

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…

> The PHP website is running PHP, but it isn’t running a web server written in PHP.

Are you sure? I'm not familiar with the PHP.net architecture, and there may be less gains from how PHP has traditionally tied itself as a module to web servers in the past, but Rails (and any number of other dynamic language frameworks) are actually web servers implemented in that language, with an optional separate web server such as NGINX or Apache you can run in front to handle the stuff they aren't as good at (static file serving, etc).

Now, that is a framework, and not the language proper, but I wouldn't be all that surprised to find python.org running on top of a Python framework.

Post reply on HN