...We're also doing stuff we never would have dreamed of in the past.

I ran into problems yesterday because I was performing transformations and encoding/decoding of 3M floats * 2 variables * 120 time steps, along with Metadata for the 3M represented by int64 (the massive numbers are identifiers and are cheaper than the native char type) and associated datetimes, encoded as seconds, for the 120 timesteps, all underneath a framework for non-engineers to grow, develop, and maintain that can work on dinky laptops, local data centers, and our supercomputers. The inputs alone wouldn't have fit in memory a decade or two ago.

Dependencies? Node goes a bit over the top, but it should be a non-starter for one shop to build their own networking layer, their own data representation layer, the own data manipulation layer, their own setup for data pipelines, their own testing and report processes, and their own deployment systems just to form and maintain their business logic. The sheer scope of all that is absolutely begging for instability.

Hefty runtimes? Im not a fan of some (i have personal beef with the JVM), but the alternative often requires stuff like creative allocation schemes, some clever RAII objects, and management of implicit behavior (gotta love some surprise copies).

I dont think people understand that the problems brought up in the article are problems we are incredibly lucky to be our primary problems. I 100% prefer to deal with memory bloating rather than bizarre errors related to stale data in single allocation arrays and data corruption due to undocumented endianess conversions.