MehdiHK
Joined 12 years ago
Joined 12 years ago
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).
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.
https://www.tomshardware.com/pc-components/nas/synology-requ...
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.
Anybody knows why?