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

Re:Case Study: Npm uses Rust for its CPU-bound bottlenecks [... by masklinn on Sunday March 03, 2019 @11:27AM (#19295213)

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 laziness can make resource usage difficult to predict.

I'd guess OCaml would also have done well in the comparison as it too combines an extensive type to system which is difficult to bypass with an eager execution model.

[ Parent | on HN ]

Re:Case Study: Npm uses Rust for its CPU-bound bottlenecks [... by platz on Sunday March 03, 2019 @11:32AM (#19295240)

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.

[ Parent | on HN ]

Re:Case Study: Npm uses Rust for its CPU-bound bottlenecks [... by Jare on Sunday March 03, 2019 @11:43AM (#19295300)

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

[ Parent | on HN ]

Re:Case Study: Npm uses Rust for its CPU-bound bottlenecks [... by platz on Sunday March 03, 2019 @11:49AM (#19295349)

Honestly just using strict data structures (one StrictData pragma will do) and strict accumulators in recursive functions will get you there, it's not that hard.

[ Parent | on HN ]