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

221–230 of 307 posts

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

#221

Post by acdha »

z3t4 wrote: post #158
GordonS wrote: post #113

Earlier quoted context omitted.

Yep, not that surprising though, given the anemic state of the JavaScript standard library.

The idea of a scripting language is that it does not have a std. It will be different in each environment. You for example don't want the same std in nodejs and the browser. Each runtime can choose what API's it want to expose.

That’s not a definition for scripting language I’ve ever heard before and it’s neither true nor desirable. Even JavaScript has a standard library - think about things like Set, Map, Regexp, Promise, etc. – because they’re universally useful, as opposed to the runtime environment where things like the DOM are less relevant to many use cases. JSON is a great example of something crossing over as an increasingly high percentage of projects will use it.

Not having a standard library on par with other scripting languages just added overhead and incompatibility for years as people invented ad hoc alternatives, often buggy. The accelerated core language growth has been hugely helpful for that but you still have issues with things as basic as the module system which exist for understandable reasons but are just a waste of developer time.

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

#222

Post by acdha »

steveklabnik wrote: post #215
acdha wrote: post #204

Earlier quoted context omitted.

That’s an ongoing annoyance with using NPM in a security-conscious environment. It’s really easy to end up with thousands of submodules and the amount of time you’ll have an audit showing a vulnerable package can be many months while layers of dependencies slowly update. You can usually show that it’s not exploitable but the number of modules on the average project means you’ll be doing that all the time.

npm now automatically reports known vulnerable packages, right?

Yes - which is great for surfacing this, along with GitHub’s alerts, but unless it’s a direct dependency I find I’m usually just stuck researching the vector and waiting months for numerous layers of dependencies to update in sequence.

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

#223

Post by tedunangst »

dbaupp wrote: post #205
kristopolous wrote: post #120

Earlier quoted context omitted.

> Every dependency specified in it's Cargo.toml will be automatically downloaded at build (if there is a new version). Why do people want this? The builds are no longer reproducible, security and edge case issues can come out of nowhere, api changes from an irresponsible maintainer can break things, network and resource failure can break the build, it's just a terrible idea. The proper use of a semvar system is entir…

You're misreading your parent. The download only happens for the first build using a new dependency. As they mention, once the version is written into the Cargo.lock file, that is the exact version that is used until there is an explicit update step run.

What does "if there is a new version" mean then? If it's a new dependency, there's no old version.

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

#224

Post by rujuladanh »

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

Learning any of C, C++, Rust or other systems languages takes way, way more than a week or a month. For C, the simplest of the three, it is usually rated at 3 months.

What happens is that if you are already proficient in one of them, one of the others takes way less time (specially in the case of C++, given it forces you to learn almost all paradigms).

In addition, writing a small program does not mean you have learnt C, C++ or Rust.

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

#225

Post by weberc2 »

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?

You can have options and have good default values for those options. Good default values are those that are reasonable for most people most of the time such that they don't need to be (or hire) domain experts to properly configure their tool.

My opinion of a bad default would include a language toolchain which defaults to dynamic linking and requires one to opt into static linking (Java, Python, JS, etc, etc, etc). Worse than that is an anorexic toolchain that has no defaults whatsoever and requires you to pass every little detail directly to the compiler--bonus points if your language has a massive ecosystem of competing tools which are meant to manage these sorts of details for you but utterly and uniformly fail to do so (looking at you, C/C++).

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

#226

Post by krferriter »

pjc50 wrote: post #220
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.

> writing the service in Node took them an hour I'm really skeptical of this unless it's just a wrapper for a thing that happens to already exist. It would be interesting to have comparative LOC numbers. > At npm, the usual experience of deploying a JavaScript service to production was that the service would need extensive monitoring for errors and excessive resource usage necessitating debugging and restarts So, the…

Fail early, fail often

deploy anyways

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

#227

Post by db48x »

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

Earlier quoted context omitted.

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

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.

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

#228

Post by dom96 »

echelon wrote: post #207
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…

This is my experience, too. I wrote trumped.com and deployed it prior to the last presidential election. The frontend and assets have been redeployed, but the core rust service for speech generation hasn't been touched. I've never had a service this reliable, and it took so little effort! Rust is the best language I've ever used, bar none, period. And I've used a countless many of them. The only places where I won't…

And what other languages have you written something like trumped.com in? What was it about them that required more effort?

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

#229

Post by dbaupp »

tedunangst wrote: post #223
dbaupp wrote: post #205

Earlier quoted context omitted.

You're misreading your parent. The download only happens for the first build using a new dependency. As they mention, once the version is written into the Cargo.lock file, that is the exact version that is used until there is an explicit update step run.

What does "if there is a new version" mean then? If it's a new dependency, there's no old version.

Yes, I suppose that's rather misleading, and that sentence contradicts with the actual behaviour that described later in the original comment. For a fixed set of dependencies, versions are only checked and changed on an explicit 'cargo update' run.

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

#230

Post by paulddraper »

bloopernova wrote: post #184
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…

It's probably just the lack of emote via text, but your reply comes off as confrontational. It's also seemingly replying to me about general Rust issues when I'm just sharing my experience of a recent Java project. I don't have much experience of Rust beyond reading some code every now and then when an interesting blog post pops up here. I'm also not condoning the decisions made in the project I describe. In fact, th…

> I don't have much experience of Rust

Oh, then that makes more sense.

It's always possible improve. But Java is pretty much king when it comes to compatibility and maintainability. (Not so much in other areas, like verbosity, language features, type system, memory overhead, etc.)

Post reply on HN