The real cost savings was from realizing the infrastructure needing nuking. Probably could have gotten almost the same savings keeping it in node and refactoring.
Go doesn't seem to be the real hero of this story.
Agree 100%.
Also changing express to deno or bun would decrease resource usage and improve overall performance with very little changes to the codebase.
2000 req per minute is pretty low.
This was nothing but an example of overengineering.
Good, now you can cut your bill again by 94% by renting a normal VPS with unlimited traffic.
The traffic is about 100x more expensive on "the cloud" and it killed all the ideas I had for cloud usage. Clouds are not worth it, even for scaling you can always rent more VPSes (or dedicated servers for heavy projects).
1990s calling: there's a language which is strongly typed, and will compile to bytecode that runs both on your server and in your browser as a sort of universal binary. It's named after a type of coffee...
MS(IE) had ActiveScript, of which VBS was just one implementation (although it was the bundled one that always existed). People have built integrations for stuff like Tcl, Python, or Perl, making them available to the browser.
addressing the category error rather than the specifics of whether js belongs in the backend - just because a language is theoretically general purpose, it doesn't mean it's the best tool for the job. in the case of language tooling in particular, the operations involved are fairly well understood, and they do not really play to the strengths of javascript (or indeed of any of the currently popular dynamic languages), because what you want is optimised performance rather than exploration of ambiguous business rules, or runtime adaptation to the shape of user data, or consuming untyped blobs from a remote API, or any of the range of other problems backend js is indeed decently useful for.
Tuesday, October 3rd, 9:17 AM. I'm sipping my coffee, opening the AWS console like I do every morning. Except this time, I almost spat it all over my keyboard.
I'm not going to give you a lecture. Here are the concrete numbers: RAM — the real deal
Node.js, on my latest version, was using 1.4 GB of RAM just to boot the app on one instance.
Go?
48 MB.
I'm not kidding. On the first test I ran, I launched a 15 MB Go binary on a t3.micro. The API responded in 20ms. I thought I'd measured wrong. I checked three times. It wasn't a mistake."
There is definitely something to be said for a self-contained high-performance server in 48 MB...
What stood out for me was that a complete rewrite of the backend application took 72 hours. Even pulling all-nighters. Especially pulling all-nighters. If I did it even 20 years ago, back when I was young, I'd expect the quality of my code to nosedive.
If it indeed took this little time, I strongly suspect the backend wasn't doing too much in the first place. Usually you can rewrite those quickly and demonstrate speedups. Some real big software that had a misfortune to have been written in something interpreted and inferior, might be more problematic, especially if you can't afford downtime or are unsure about all important corner cases, and when the program itself is your only documentation.
Another thing that was very jarring was that the article as a whole sounded very LLMese. Or PowerPointy? Take your pick. This little example screams that an LLM might likely have writen it:
> I'm not going to give you a lecture. Here are the concrete numbers:
> RAM — the real deal
>
> Node.js, on my latest version, was using 1.4 GB of RAM just to boot the app on one instance.
>
> Go? 48 MB. I'm not kidding.
When talking to LLMs, I cannot now unsee how often they feel a need to assert something is real and they are not making things up. When I see this much LLM-like writing, I'm asking myself, maybe this all is made up? A plausible story, but maybe it never happened? Why would I spend my time reading it?
The real cost savings was from realizing the infrastructure needing nuking. Probably could have gotten almost the same savings keeping it in node and refactoring. Go doesn't seem to be the real hero of this story.
Agree 100%. Also changing express to deno or bun would decrease resource usage and improve overall performance with very little changes to the codebase.
2000 req per minute is pretty low. This was nothing but an example of overengineering.
In a sane world this would still pass as satire.
In our world I'm not sure whether a human even read the entire thing before publishing it. There's absolutely nothing of substance in here.
it's AI slop, same as everything posted by that user (look at their comments)... :\
A rewrite is always better... I bet you could rewrite in bash with fastcgi and get an improvement
The site redirected/presented me with a full screen "Your phone has been wiretapped, click here" type ads/scam
Good, now you can cut your bill again by 94% by renting a normal VPS with unlimited traffic.
The traffic is about 100x more expensive on "the cloud" and it killed all the ideas I had for cloud usage. Clouds are not worth it, even for scaling you can always rent more VPSes (or dedicated servers for heavy projects).
Well, another one discovering strongly typed compiled languages.
Apparently Tiger Beetle also started in node, before the founder reached out for Zig.
Meanwhile all JavaScript tooling is being rewritten in Go and Rust.
Maybe it is time to finally grasp it should be left to the browser?
Or maybe that it should be replaced in the browser with something better as well?
1990s calling: there's a language which is strongly typed, and will compile to bytecode that runs both on your server and in your browser as a sort of universal binary. It's named after a type of coffee...
MS had VBS. Just sayin
MS(IE) had ActiveScript, of which VBS was just one implementation (although it was the bundled one that always existed). People have built integrations for stuff like Tcl, Python, or Perl, making them available to the browser.
Example: https://perlhacks.com/2026/07/remember-perlscript-when-inter...
Linked article is AI slop. Am I going crazy?
Well the actual pages from that time are mostly gone and that was what I could find with some examples and explanatory text.
addressing the category error rather than the specifics of whether js belongs in the backend - just because a language is theoretically general purpose, it doesn't mean it's the best tool for the job. in the case of language tooling in particular, the operations involved are fairly well understood, and they do not really play to the strengths of javascript (or indeed of any of the currently popular dynamic languages), because what you want is optimised performance rather than exploration of ambiguous business rules, or runtime adaptation to the shape of user data, or consuming untyped blobs from a remote API, or any of the range of other problems backend js is indeed decently useful for.
[flagged]
Tuesday, October 3rd, 9:17 AM. I'm sipping my coffee, opening the AWS console like I do every morning. Except this time, I almost spat it all over my keyboard.
[dead]
You never mentioned what is this BE for?
BE = Advertisement banner (abbreviation for "Banner")
>"Why Go saved my a*
I'm not going to give you a lecture. Here are the concrete numbers: RAM — the real deal
Node.js, on my latest version, was using 1.4 GB of RAM just to boot the app on one instance.
Go?
48 MB.
I'm not kidding. On the first test I ran, I launched a 15 MB Go binary on a t3.micro. The API responded in 20ms. I thought I'd measured wrong. I checked three times. It wasn't a mistake."
There is definitely something to be said for a self-contained high-performance server in 48 MB...
This is AI slop
Looks like you hit paste 2x bro. : )
Came here to say this, the entire article is duplicated on the page.
Did you keep RDS Postgres?
What stood out for me was that a complete rewrite of the backend application took 72 hours. Even pulling all-nighters. Especially pulling all-nighters. If I did it even 20 years ago, back when I was young, I'd expect the quality of my code to nosedive.
If it indeed took this little time, I strongly suspect the backend wasn't doing too much in the first place. Usually you can rewrite those quickly and demonstrate speedups. Some real big software that had a misfortune to have been written in something interpreted and inferior, might be more problematic, especially if you can't afford downtime or are unsure about all important corner cases, and when the program itself is your only documentation.
Another thing that was very jarring was that the article as a whole sounded very LLMese. Or PowerPointy? Take your pick. This little example screams that an LLM might likely have writen it:
When talking to LLMs, I cannot now unsee how often they feel a need to assert something is real and they are not making things up. When I see this much LLM-like writing, I'm asking myself, maybe this all is made up? A plausible story, but maybe it never happened? Why would I spend my time reading it?another good target for ai rewrite: getting out of serverless cost hell.
it used to be a gigantic endeavor. now a few days work.