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

191–200 of 307 posts

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

#191

Post by itiman »

fpgaminer wrote: post #160
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…

I wrote and deployed a production service written in pre-1.0 Rust. In over three years of being deployed I never once had to touch that code. The infrastructure around it evolved several times, we even moved cloud providers in that time, but that particular service didn't need any changes or maintenance. It just kept chugging along. Perhaps Rust's name is apropos: your code will be so reliable that you won't need to…

I to have written a service that still runs and never touched it’s code since. I think I used COBOL.

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

#192

Post by db48x »

0815test wrote: post #128
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…

> any Github Rust project not updated in the last two years doesn't work with the latest Rust compiler. I don't think this is correct? Rust introduced an "editions"-based system in 2015, with the very aim of ensuring forward compatibility on a crate-by-crate basis. The aim is definitely that any crate written to be compatible with some "edition of Rust", whether 2015, 2018 or whatever, can be made to compile on a fut…

One possibility is that he used something written against the nightly Rust compiler. That code would be very unlikely to compile today.

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

#193

Post by shaklee3 »

tejasmanohar wrote: post #126
breatheoften wrote: post #110

Earlier quoted context omitted.

Are CTO's of largish organizations still not part of the hacker news audience ...? That seems a bit of a damning statement to be about the population of CTO's ...

I'm sure some are on HN, but it's definitely not "the place" for them, and many have probably never heard of it

I would be shocked if any CTOs of large organizations browse HN. Large orgs put people in those positions that are more about theory and future thinking over current knowledge.

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

#194

Post by todd3834 »

z3t4 wrote: post #183
fpgaminer wrote: post #160

Earlier quoted context omitted.

I wrote and deployed a production service written in pre-1.0 Rust. In over three years of being deployed I never once had to touch that code. The infrastructure around it evolved several times, we even moved cloud providers in that time, but that particular service didn't need any changes or maintenance. It just kept chugging along. Perhaps Rust's name is apropos: your code will be so reliable that you won't need to…

Never touched code is seldom a sign of quality. But there's the old saying; if it ain't broken, don't fix it.

Another saying, “broken gets fixed but shoddy lasts forever”.

Edit: this seems like I’m suggesting rust makes shoddy results. Didn’t mean to imply that. I’m actually very excited to use Rust in prod soon.

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

#195

Post by adamnemecek »

c-smile wrote: post #186
adamnemecek wrote: post #12

I’ve been playing around with rust since it came out but only recently did I decide to use it for a part of a project. It’s a very pleasant language. I didn’t fight the borrow checker much (maybe due to prior experience). The language is nuts. It’s true what they say cargo is even better than the language, it’s just so easy to add packages to your project or to split your project into packages. Cargo is an amazing in…

> write non duplicated code ... Like how many string implementations are there across c code bases. In one of projects I needed foo::string that can share data with foo::variant without copying the data each time. So foo::string was implemented as a COW string - smart pointer for foo::string_data. std::string simply does not work in such requirements. So I am not sure I understand how cargo will help in this case. Ei…

Your problem isn't hard to solve in Rust. Reasoning about allocations is a foundational idea of Rust and is solved using lifetimes.

Basically, lifetimes are allocators as a first-class language construct. You can reason about what happens if values are stack or heap allocated and specialize your code based on that. Lifetimes are definitely an advanced feature and I think you can do some crazy optimizations with them. But your use case is not hard to implement. If you show me the C++, I'll show you how to achieve the same semantics.

Cargo helps because Rust lets you build cleaner abstractions and abstractions that compose nicer. So integration is super easy.

> For typical web front-end projects NPM or Cargo probably make sense.

I might misunderstand your sentence, but neither Rust nor cargo are for front-end?

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

#196

Post by cle »

BlackFly wrote: post #53

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

This is not at all outdated. GraalVM and SubstrateVM are still very new and only support a subset of JVM features. The Vert.x article itself mentions that, as well as this:

https://github.com/oracle/graal/blob/master/substratevm/LIMI...

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

#197

Post by patrec »

pjmlp wrote: post #163
patrec wrote: post #147

Earlier quoted context omitted.

One wonders if there'll be a similar talk in a year... > The audience walks away feeling empathetic that they aren’t alone in their journey to writing idiomatic Go and is now equipped with strong refactoring techniques developed by some of the world’s top engineers for the Kuberentes project. As an occasional user of kubernetes, minikube etc. it's not something I would have guessed to have been developed by the word'…

You would be surprised at the quality of Android tooling stable releases, to the point that now there is Project Marble in place to try to improve its image. https://adtmag.com/articles/2019/01/17/project-marble.aspx If you want to have some reading fun, check /r/androiddev/ every time there is a "stable" release.

Even people working for Google on Android tell me the tooling is pretty garbage, so I'm less surprised than you might think ;)

The interesting thing with Kubernetes is that it's basically a re-imagining of Borg, which one assumes was not a few million lines of code when it was already running all of Googles infra more than a decade ago. It's obviously not solving the exactly same problem (e.g. Google correctly recognized that DNS isn't so hot and wrote their own replacement protocol, BNS which wouldn't fly for external adoption etc.). But I'd be curious to know how Borg's code quality and size back when it became the standard way to run stuff at Google maybe 12 years ago compares to Kubernetes today.

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

#198

Post by saagarjha »

fpgaminer wrote: post #160
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…

I wrote and deployed a production service written in pre-1.0 Rust. In over three years of being deployed I never once had to touch that code. The infrastructure around it evolved several times, we even moved cloud providers in that time, but that particular service didn't need any changes or maintenance. It just kept chugging along. Perhaps Rust's name is apropos: your code will be so reliable that you won't need to…

Interestingly, Graydon has mentioned in the past that he may have named the language after the fungi.

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

#199

Post by saagarjha »

spdionis wrote: post #169
zukzuk wrote: post #59

Earlier quoted context omitted.

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

Except that npm will gladly update your lock file when you run npm install which is insane.

…so would Cargo? If you install a new package, why wouldn’t you expect it to show up in your lock file?

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

#200

Post by 0815test »

db48x wrote: post #192
0815test wrote: post #128

Earlier quoted context omitted.

> any Github Rust project not updated in the last two years doesn't work with the latest Rust compiler. I don't think this is correct? Rust introduced an "editions"-based system in 2015, with the very aim of ensuring forward compatibility on a crate-by-crate basis. The aim is definitely that any crate written to be compatible with some "edition of Rust", whether 2015, 2018 or whatever, can be made to compile on a fut…

One possibility is that he used something written against the nightly Rust compiler. That code would be very unlikely to compile today.

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).
Post reply on HN