3 ms·
node is based on various libraries, among them, v8 and libuv. v8, is a JavaScript engine. An oversimplified way to describe it, is that it has an interpreter a
by 29athrowaway 6y ago
node is based on various libraries, among them, v8 and libuv.
v8, is a JavaScript engine. An oversimplified way to describe it, is that it has an interpreter and a JIT compiler. Compiled code is faster, but not all code is elegible for that. If you write code that can be optimized by v8, it can run very, very fast. Most of the time v8 will give you decent performance but if you want to maximize performance by minimizing deoptimizations (e.g.: tracing compiler behavior using --trace-opt --trace-deopt CLI arguments)... you will be consuming more time than using Rust.
libuv is a crossplatform library written in C that handles all the heavy lifting for node. Using libuv, node creates an event loop and a thread pool, where asynchronous operations can be scheduled and executed concurrently. It also takes care of file I/O and networking.
node gives you a decent level of performance when you can delegate most of the work to libuv, or built-in JavaScript functions. But when running user-defined code that is CPU bound, node is not the right tool for the job. CPU bound tasks tend to block the event loop, or make ticks long enough so that it becomes a problem.
Blocking or slowing down the event loop causes time sensitive tasks scheduled for future event loop ticks, such as processing events from sockets, to timeout. This can be prevented using worker threads, which are a recent addition to node... but almost all of node and its package ecosystem has been built around the absence of user-facing threads.
node can be used to build robust, highly available, performant and secure systems, but you need to know what you are doing and what the limits are. I think node is not the right tool for every job, but when it is, it can be highly productive and save time.
Security-wise, node is hard to audit. Packages tend to have many dependencies, and many packages are not built with security in mind. JavaScript itself is a languge that has been built with browser security in mind, but also, JavaScript is a language where almost everything is mutable, including built-in types. Prototype pollution is a big problem.
Rust is more flexible, doesn't impose you a threading model, you have access to many concurrency primitives, and all your code will be compiled in a much predictable way. I am not familiar with the security aspects of Rust. At least it seems much safer than C, where it is not hard to create unsafe code.
- steveklabnik 6y agoFun Trivia Fact: long ago, the Rust runtime (when it existed) had libuv in it too!
- jpgvm 6y agoI actually sort of miss the early green threaded Rust that I first played with. I understand why that direction was abandoned and I'm happy with how Rust turned out but I do wish for a "better Golang". i.e Rust + a green threaded runtime that lets me write blocking code that is automatically async with M:N threading model. maybe one day Rust can do that too ala Java Loom.
- steveklabnik 6y agoYeah, there is certainly room for an interesting language in that kind of space. I don't think Rust can or will ever choose that, Loom works because Java already has a runtime. It'd be a much bigger step for Rust.