4 ms·

NodeJS is my primary stack, and I've built toy projects with Rust since 2014, but never used it in production. Rust offers perfomance improvements in CPU and m

NodeJS is my primary stack, and I've built toy projects with Rust since 2014, but never used it in production. Rust offers perfomance improvements in CPU and memory usage of the core application logic, and it's almost never the bottleneck for the typical web apps. Almost always, they're limited by IO, and I don't see any reasons why it would be better on Rust that on Node. Also, Rust offers security of safe access to memory, but that's a problem that exists in C and C++, not in GC-based languages. Finally, Rust offers a great type system, but Typescript has a very good one as well, and offers a much easier transition for Javascript Node developers, as well as a much more machure NPM ecosystem. Overall, I just don't see how Rust would make much of an improvement over existing state of affairs.

cwaffles 6y ago
Rust offers a few things over Node in my experience: - Super fast startup - Single binary distribution (you can integrate your static assets with rust-embed) - Minuscule ram consumption (0.5MB for a graphql server) - Cargo build system is much easier to work with than webpack - No mismatches between TS types and JS source However the big caveat is the documentation and libraries are still quite lacking
- golergka 6y ago
  Anything but the last one doesn't really matter for my case. NodeJS app startup takes about 4-5 seconds at most. Binary could theoretically be well into gigabytes for it to make any difference. I'm a pure backend developer, so I don't use webpack. And the mismatch between TS and JS is a pain, but that's why I'm looking forward to Deno.
staticassertion 6y ago
> Rust offers perfomance improvements in CPU and memory usage of the core application logic, and it's almost never the bottleneck for the typical web apps. Has anyone actually managed to find that this is the case? Just because your app is stalling on db queries doesn't mean it's "IO bound". Even the most trivial service that's just routing messages between two other services is likely to be radically faster when implemented in Rust vs JS.
- jashmatthews 6y ago
  Almost every web app. Exceptions are stuff like dynamic map tile generation. Even WhatsApp scale runs on a “slow” dynamic language.
  - staticassertion 6y ago
    I'm not sure what you mean. > Almost every web app. No? My point is exactly that almost every web app is not io bound. They're just... slow. They write bad queries, they make bad usage of resources and block on requests, etc. > Even WhatsApp scale runs on a “slow” dynamic language. But that has nothing to do with being IO bound. Whatsapp, via Erlang, works by having tons of connections on a single box. And you can watch plenty of talks by them about how they've had to work with BEAM to get Erlang to actually be IO bound. "IO bound" is a meme. Most people just mean "my queries are slow". Unless you're saturating your NIC, you're not io bound with regards to throughput, and unless your queries execute in ~<100ns you probably aren't IO bound on latency either.
    - btrask 6y ago
      You're right that most web apps aren't actually "IO bound" per se. They aren't making optimal or maximal use of either network or disk IO. However the important point is that they aren't CPU bound either. Most are "user acquisition bound" (like tens of requests per second peak). Some are more like "developer time bound" (cutting the server farm in half is not worth the cost in dev time). Either way, using a slow development framework (including language, DB, etc.) that the developers like is a reasonable choice for what they're trying to do. (I personally wish most software was faster, but they have no reason to care what I think.)
      - staticassertion 6y ago
        I'm in full agreement that you can prioritize other things over efficiency, and that a framework in a slower language can be the right call.
jokethrowaway 6y ago
Typescript allows you to have massive gaps in your types. I've been bitten by it so many times. As a huge proponent of types, sometimes I think it would be better not to have it, because of the trust you put in your type system and the mental load of always keeping in mind "oh wait, maybe someone is using this as any somewhere". Node event loop GC pauses are also a problem and they contribute to instability and timeouts. Rust can make app performance easier to reason about, improve performance, bring a real type system and all of this with a language which is just marginally harder to learn.
- golergka 6y ago
  Could you please share your stories? I've been bitten by the difference between Typescript compile-time and Javascript run-time in the past, but I've come to learn their limitations and ways to overcome them. > oh wait, maybe someone is using this as any somewhere There's a single option to disable any in all of your codebase. I've also found `unknown` type very useful for situations where you just don't care about what type you have, but would've had to use `any` before.

cwaffles 6y ago

Rust offers a few things over Node in my experience: - Super fast startup - Single binary distribution (you can integrate your static assets with rust-embed) - Minuscule ram consumption (0.5MB for a graphql server) - Cargo build system is much easier to work with than webpack - No mismatches between TS types and JS source However the big caveat is the documentation and libraries are still quite lacking

golergka 6y ago
Anything but the last one doesn't really matter for my case. NodeJS app startup takes about 4-5 seconds at most. Binary could theoretically be well into gigabytes for it to make any difference. I'm a pure backend developer, so I don't use webpack. And the mismatch between TS and JS is a pain, but that's why I'm looking forward to Deno.

staticassertion 6y ago

> Rust offers perfomance improvements in CPU and memory usage of the core application logic, and it's almost never the bottleneck for the typical web apps. Has anyone actually managed to find that this is the case? Just because your app is stalling on db queries doesn't mean it's "IO bound". Even the most trivial service that's just routing messages between two other services is likely to be radically faster when implemented in Rust vs JS.

jashmatthews 6y ago
Almost every web app. Exceptions are stuff like dynamic map tile generation. Even WhatsApp scale runs on a “slow” dynamic language.
- staticassertion 6y ago
  I'm not sure what you mean. > Almost every web app. No? My point is exactly that almost every web app is not io bound. They're just... slow. They write bad queries, they make bad usage of resources and block on requests, etc. > Even WhatsApp scale runs on a “slow” dynamic language. But that has nothing to do with being IO bound. Whatsapp, via Erlang, works by having tons of connections on a single box. And you can watch plenty of talks by them about how they've had to work with BEAM to get Erlang to actually be IO bound. "IO bound" is a meme. Most people just mean "my queries are slow". Unless you're saturating your NIC, you're not io bound with regards to throughput, and unless your queries execute in ~<100ns you probably aren't IO bound on latency either.
  - btrask 6y ago
    You're right that most web apps aren't actually "IO bound" per se. They aren't making optimal or maximal use of either network or disk IO. However the important point is that they aren't CPU bound either. Most are "user acquisition bound" (like tens of requests per second peak). Some are more like "developer time bound" (cutting the server farm in half is not worth the cost in dev time). Either way, using a slow development framework (including language, DB, etc.) that the developers like is a reasonable choice for what they're trying to do. (I personally wish most software was faster, but they have no reason to care what I think.)
    - staticassertion 6y ago
      I'm in full agreement that you can prioritize other things over efficiency, and that a framework in a slower language can be the right call.

jokethrowaway 6y ago

Typescript allows you to have massive gaps in your types. I've been bitten by it so many times. As a huge proponent of types, sometimes I think it would be better not to have it, because of the trust you put in your type system and the mental load of always keeping in mind "oh wait, maybe someone is using this as any somewhere". Node event loop GC pauses are also a problem and they contribute to instability and timeouts. Rust can make app performance easier to reason about, improve performance, bring a real type system and all of this with a language which is just marginally harder to learn.

golergka 6y ago
Could you please share your stories? I've been bitten by the difference between Typescript compile-time and Javascript run-time in the past, but I've come to learn their limitations and ways to overcome them. > oh wait, maybe someone is using this as any somewhere There's a single option to disable any in all of your codebase. I've also found `unknown` type very useful for situations where you just don't care about what type you have, but would've had to use `any` before.