I didn't say multithreading anywhere. Mutitasking (concurrency) != Multithreading.
You can do pre-emptive concurrency with a single thread in other runtimes, where each task gets a pre-defined amount of CPU time slice, that solves fair scheduling for both IO and CPU-bound workloads. Nobody is supposed to pick NodeJS for CPU-bound workload, but you cannot escape JSON parse/stringify event-loop blocking in practice (which is CPU-bound).
> JSON.stringify was one of the biggest impediments to just about everything around performant node services
That's what I experienced too. But I think the deeper problem is Node's cooperative multitasking model. A preemptive multitasking (like Go) wouldn't block the whole event-loop (other concurrent tasks) during serializing a large response (often the case with GraphQL, but possible with any other API too). Yeah, it does kinda feel like amateur hour.
Not related to VPC, but I'm a big fan of the author. Loved his book "Grokking Algorithms: An Illustrated Guide for Programmers and Other Curious People" when it came out a few years ago. If you know anyone struggling with common data structures and algorithms, this book can make it fun for them.
I'd also add that code readability goes a long way too. Rust compiler has better checks than Go, but when LLMs make mistakes it's a lot easier to identify and fix generated Go code than Rust.
So the balance between verbosity and readability is important too, in addition to soundness checks. Java and Go are both verbose, but Go is intentionally designed for readability.
And compile time as already mentioned. Go wins there too.
All of these help together to iterate faster with fast and often subtly wrong generated code. LLMs will continue to be less wrong as the available training samples increase over time. That's something for the future to see what wins there.
I use revanced for this on Android. Pretty cool, adblocker, sponsor block, customization like removing shorts. It patches YouTube APK, so you retain same UX, no need to use a new app.