> The sin is this ridiculous era of every program shipping its own runtime. I'm headed for real down votes, but this is the same lazy culture that's taken over everywhere: go and rust both ship these huge statically compiled binaries.
Go and Rust are pretty efficient too, if your architecture isn't trash. If it is, they still probably are more efficient than Electron
Rust and go are somewhere on the continuum, between dynlibs and chrome, for how much private world they build for themselves. It's vastly less than chrome. But it's a lot. A lot more than what Linux distributions did for years and years and years.
Especially if you think if multiuser systems with multiple people using programs, then you have some scaling factor. Then it matters a lot a lot more than each lib has to be loaded distinctly for each process.
It's not good. It's not good for Electron, there are vastly better ways to run many apps taking a more dynlib path, and it's not good for rust or go. As nice as it is to dev like that.
Of course it's another huge problem that dependency trees are rarely shared. Go look at Class Data Sharing in Java: building the libs you standardize on (your orgs stdlibs) and there's this beautiful idea here that you should just already have some common things expected to be there. That's harder to imagine since so many programs have such different dep stacks. But imagine having a Tokio or tokio+++ that everyone can use, good foundational tools (Grand Central dispatch and the never arrived NextBSD) Some common substrate, with just like async as one example. And the size of that shared good useful library/platform can grow, hopefully revive an interest in reuse vs bringing your own every time. https://docs.oracle.com/en/java/javase/17/vm/class-data-shar...