I agree. I like functional programming, but at some point, you're going to have some type of encapsulation, whether at the closure, module, actor, or network boundary. It's always important to think about what API you're exposing.
There's an important distinction, however, between redistribution that seeks to create a more free and just society and retribution that seeks to prevent a society without consumers.
Most tech people in favor of redistributive schemes like UBI are in favor of the later.
Ah, well, I'm in favor of UBI and both of the reasons you mention for it - the free market is still the best way we've found to allocate resources to worthwhile projects.
What if I have an application that needs to be deployed internally and externally in separate instances. Identical application, but different security contexts. Using Nginx to handle these concerns is easy.
It's a common myth that internal networks are a more secure environment. You are better off implementing the philosophy behind something like Google's BeyondCorp¹ effort.
Yeah, but nobody relies on the execution order of disparate callbacks to achieve their results in JS. You're going to get burned in like two seconds if you try to do anything you listed. Lower level concurrency primitives in other languages allow developers to build fragile solutions which work 99% of the time until they deadlock and everything blows up. The concurrency model in JS is very explicit about being "no guaruntees."
There are many reasons why complex software fails in the 1% case. Concurrency is not the only reason. In my experience it is not the top reason. Our top hard-to-repro or no-repro crashes in JavaScriptCore are from non determinism introduced by the workload itself. Inside our engine we have many sources of nondeterminism that manifests even with concurrency features disabled.
I think the distinction is that a breaking API change breaks some of your code, a backward incompatible change breaks your entire codebase -- i.e., fix a few method signatures vs refactor your entire codebase.
Obviously the shareholders want the business to focus on whats the most profitable. iPhone seems basically to be a license to print money for Apple.
Still, I think there are two arguments:
They are sitting on so much cash. There is obviously a cultural or organizational problem that produces to much friction to keep this product line up to date. I'm fairly certain many other corporations, if provided access to basically infinite cash, could figure out how to put new ram in an existing product line every year.
There's huge value in having creative professionals and developers use your product. Keeping people in your ecosystem is important. This might be hard to quantify on the bottom line, but it seems like an obvious strategic mistake to give up this advantage.
