Comment by staticassertion
2 days ago
I had a script in another language. It was node, took up >200MB of RAM that I wanted back. "claude, rewrite this in rust". 192MB of memory returned to me.
2 days ago
I had a script in another language. It was node, took up >200MB of RAM that I wanted back. "claude, rewrite this in rust". 192MB of memory returned to me.
Solving the big RAM shortage one prompt at a time.
This is sad to see. Node was originally one of the memory efficient options – it’s roots are solving the c10k problem. Mind sharing what libraries/frameworks you were using?
> it’s roots are solving the c10k problem
The C10K was a long-solved problem when Node came out; just it was not for what 99% of people used at the time, i.e. PHP/Python/Ruby.
It was an express server. I don't think c10k is particularly interesting since it mostly just involves having cooperating scheduling. Doesn't really impact flat memory overhead etc. I mean, the binary for node alone, without any libraries etc, is larger than the produced rust binary.
Before Node/libuv holding open connections was really expensive resource-wise, dropping that cost to <30KB per connection was massive.
The node binary is huge due to inclusion of i18n libraries to support the native APIs, and should have little impact on memory consumption. There is a way to opt out.
I used to have a bunch of bespoke node express server utilities that I liked to keep running in the background to have access to throughout the day but 40-50mb per process adds up quickly.
I’ve been throwing codex at them and now they’ve all been rewritten in Go - cut down to about 10mb per process.