> 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.
That's not really a Node problem but a JavaScript problem. Nothing about it was built to support parallel execution like Go and other languages. That's why they use web workers, separate processes, etc. to make use of more than a single core. But then you'll probably be dependent on JSON serialization to send data between those event loops.
I'm not a Node dev, but I've done some work with JavaScript on the web. Why are they using JSON to send data between v8 isolates when sendMessage allows sending whole objects (using an implementation defined binary serialization protocol under the hood that is 5-10x faster)?
The biggest reason is most likely that they don't understand serialization, and simply think that objects are somehow being "sent" from one worker to another, which sounds like a cheap reference operation.
> That's not really a Node problem but a JavaScript problem.
Nowadays Node is JavaScript. They are the guys driving JavaScript standards and new features for a decade or so. Nothing prevents them from incrementally starting to add proper parallelism, multithreading, ...
I disagree - JavaScript is the most used programming language in the world, and were I a betting man I'd happily wager client JS is still a much bigger share of that than server.
Yes, there have been a lot of advances in modern JS for things like atomics and other fun memory stuff, but that's just the natrual progression for a language as popular as JS. The 3 main JS engines are still developed primarily for web browsers, and web developers are the primary audience considered in ES language discussions (although I'll concede that in recent years server runtimes have been considered more and more)
>I disagree - JavaScript is the most used programming language in the world, and were I a betting man I'd happily wager client JS is still a much bigger share of that than server.
Clients are 90% still v8, so hardly different than Node.
"Nothing prevents them from incrementally starting to add proper parallelism, multithreading, ..."
In principle perhaps not. In practice it is abundantly clear now from repeated experience that trying to retrofit such things on to a scripting language that has been single-threaded for decades is an extremely difficult and error-prone process that can easily take a decade to reach production quality, if indeed it ever does, and then take another decade or more to become something you can just expect to work, expect to find libraries that use properly, etc.
I don't think it's intrinsic to scripting languages. I think someone could greenfield one and have no more problems with multithreading than any other language. It's trying to put it into something that has been single-threaded for a decade or two already that is very, very hard. And to be honest, given what we've seen from the other languages that have done this, I'd have a very, very, very serious discussion with the dev team as to whether it's actually worth it. Other scripting languages have put a lot of work into this and it is not my perception that the result has been worth the effort.
NodeJS is intended for IO-heavy workloads. Specifically, it's intended for workloads that don't benefit from parallel processing in the CPU.
This is because Javascript is strictly a single-threaded language; IE, it doesn't support shared access to memory from multiple threads. (And this is because Javascript was written for controlling a UI, and historically UI is all handled on a single thread.)
If you need true multithreading, there are plenty of languages that support it. Either you picked the wrong language, or you might want to consider creating a library in another language and calling into it from NodeJS.
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).
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.
Telepresence mainly tunnels traffic from existing services within Kubernetes namespaces.
Kloudlite, on the other hand, orchestrates environments and managed services, connecting them to workspaces without exposing Kubernetes APIs to the end user.
From a networking perspective, Kloudlite offers technical advantages. It operates at OSI Layers 3 and 4 using a WireGuard network, while Telepresence functions primarily at Layer 7 and partly at Layer 4 using application proxies. Because Kloudlite works at Layer 3, it provides a higher level of abstraction for connecting services and devices.
You can link multiple clusters—including your local machine—within your team. All environments and services managed by Kloudlite become part of the same WireGuard network.
For example, you can create a shared database in a remote cloud cluster, clone environments and apps to a local cluster, and start development. Another developer on a different machine can easily switch to your environment and access the same services, enabling seamless collaboration. Since Kloudlite uses a WireGuard network, any device with a WireGuard client can connect to access these services.
Good question! Scraping and ingestion continues to use dedicated compute.
Serverless helps with query performance. Queries can be parallelized with serverless functions, this especially helps with long range queries. As an added advantage, compute does not have to be pre-provisioned for queries.
