Hacker News Reader

Comment by Ginden | Hacker News Reader

> And yet, I rarely hear people suggest or even evaluate the solution of embedding a native module that most of the times will be faster.

Because there's rarely a real benefit to this approach.

I have yet to found use case where C/C++/Rust library is useful AND spawning process to do heavy work is not a viable option AND JS-only library won't work.

I can think basically only about communication with external resource like database.

View on HN

We're doing exactly this in our language libraries for Tangram. Our core machine learning code is written in Rust and we use a native add-on so people can make predictions directly from their javascript apps. In Python, this is incredibly common: NumPy, LightGBM, XGBoost are written in C/C++ and exposed to Python.

A really common use case that comes to mind immediately: parsing and AST transforms. Quite common in build tooling, quite noticeable performance difference as evidenced by SWC. (ESBuild doesn’t expose its AST, but it’s also quite a lot faster than comparable plain JS at what it does expose in its JS interface).

The performance difference between webpack and esbuild is like night and day

I wrote about use case where "spawning process to do heavy work is not a viable option". ESBuild DOES spawn process to do heavy work.

https://github.com/evanw/esbuild/blob/11d7eacd491c94d2aa23cd...

You’re correct. I didn’t cite ESBuild as a use case, I mentioned it to give credit where it was due.

I can think basically only about communication with external resource like database.

And when it is a database, all the benefits of a compiled language turn into just a fancy no-brainer wrapper which still sucks because of “impedance mismatch”. It would be nice if that was true jit-integrated rust or at least C ffi, which one could call directly from js. But I don’t think that v8 will get such capability in observable future.

Reply on news.ycombinator.com