> They could have built this in Java, .Net, Go, really any shared memory concurrency runtime and threading, and would not run into any of these issues.
It is funny how you can get away with using the wrong tool for the job in Software in a professional environment. Like imagine if you were hired to build a house, and you decided to build the foundation out of modeling clay because that's what you're used to working with. And then you started to come up with novel methods of hardening modeling clay when it proved not to be fit for purpose.
I guess you can get away with it in software because these kinds of decisions normally only manifest as increased server costs, or moments of users' lives lost to performance issues, which are much less evident to the outside observer.
Funny you should take this example. Unless you're building a skyscraper, for 1-2 floors clay is plenty good: in particular when mixed with wheat or other fibrous bodies (straw type), it's how many traditional houses have been built, and has many interesting properties:
- sourced from local material (use a different type of clay or straw if you need), no need for chemicals or for sand imports from depleted beaches on the other side of the world
- recyclable to almost infinity (need a bigger/better house? just tear it down and reuse the materials)
- cool in summer, warm in winter if you design it well
- lasts for decades if your structure is designed well: i'm not aware of really old examples but it would be a surprise if the structure outlives us all (does someone have resources on this topic?)
So turns out your example was more interesting and less absurd than you originally thought. Just like server-side rendering uses an order of magnitude less resources (for n clients it's O(1) with caching, whereas client-side rendering is O(n)), it turns out clay is the perfect material to use an order of magnitude (or even more orders?) less resources to build your house than if you used concrete source from various polluting industries and endangered sand deposits.
Fair point re clay foundations, but I was talking about the tooling choice for server-side rendering, not server-side rendering itself. For instance if they had implemented this in Erlang or Go they likely wouldn't have run into this GC bottleneck they had to engineer around to be able to exceed 50 requests per second.
I'm a big fan of server-side rendering and am sure it could be used way more often to great effect.
It is funny how you can get away with using the wrong tool for the job in Software in a professional environment. Like imagine if you were hired to build a house, and you decided to build the foundation out of modeling clay because that's what you're used to working with. And then you started to come up with novel methods of hardening modeling clay when it proved not to be fit for purpose.
I guess you can get away with it in software because these kinds of decisions normally only manifest as increased server costs, or moments of users' lives lost to performance issues, which are much less evident to the outside observer.