I don't fully agree with this. Yes, surely shared mutable state can suffer from similar issues, however the cooperative nature of coroutines makes this much easier to handle. OS threads are preemptive and actually run in parallel, so you have to be aware of CPU concurrency and always be ready for a context switch.
Hard disagree. Co-routines are utter hell. They should have never become popular.
With traditional locking, the locked segment is usually very clear. It's possible to use race detectors to verify that objects are accessed with consistent locking. The yield points are also clear.
With async stuff, ANY await point can change ANY state. And await points are common, even sometimes for things like logging. There are also no tools to verify the consistent "locking".
So I often spend hours staring blankly at logs, trying to reconstruct a possible sequence of callbacks that could have led to a bug. E.g.: https://github.com/expo/expo/issues/39428
Memory access performance depends on the _maximum size of memory you need to address_. You can clearly see it in the graph of that article where L1, L2, L3 and RAM are no longer enough to fit the linked list. However while the working set fits in them the performance scales much better. So as long as you give priority to the working set, you can fill the rest of the biggest memory with whatever you want without affecting performance.
Italy's digital ID (SPID) works by having multiple trusted providers that can attest your identity. You can sign up with multiple of them, and if one is not available you could use another one. Not perfect (it's still centralized in the hand of 10-20 providers) but better than nothing. Unfortunately most people only ever signed up with one provider, and the government is now pushing for a more centralized digital ID istead (CieID).
All of these IDs in the EEA are based on a common set of EU requirements, and in theory that means multiple providers, but in practice in many countries the set of providers is small and with feature gaps. E.g. Norway has several providers, but they provide different levels of security and features, which means in practice most people rely on BankID...
10-20 is fantastic in comparison. Even if people don't have more than one it at least reduces the blast radius..
At the company I work at we have turnstiles that you open with an app on your phone, however the reason seems to be to know if anyone is in the elevators in case of emergency.
Not sure about Block and Paypal, but AFAIK a good portion of transactions on Stripe are made as part of recurring subscriptions or similar. Those can't be migrated to other services easily, so for the time being Stripe will likely continue profiting from them and from the growth of whatever businesses use it for such subscriptions.
On the consumer facing side Paypal is something I use when paying, but AFAIK I can't use Stripe (yet?). Stripe is used by businesses to let me pay with a credit card (or Paypal, Google Pay, etc etc).
> Except as you well know, C might not change as fast, but it does change, including the OS ABI.
I don't know that.
Here's what I know: the most successful OSes have stable OS ABIs. And their market share is positively correlated with the stability of their ABIs.
Most widely used: Windows, which has a famously stable OS ABI. (If you wanted to be contrarian you could say that it doesn't because the kernel ABI is not stable, but that misses the point - on Windows you program against userland ABIs provided by DLLs, which are remarkably stable.)
Second place: macOS, which maintains ABI stability with some sunsetting of old CPU targets. But release to release the ABI provides solid stability at the framework level, and used to also provide stability at the kernel ABI level (not sure if that's still true - but see above, the important thing is userland framework ABI stability at the end of the day).
Third place: Linux, which maintains excellent kernel ABI stability. Linux has the stablest kernel ABI right now AFAIK. And in userland, glibc has been investing heavily in ABI stability; it's stable enough now that in practice you could ship a binary that dynlinks to glibc and expect it to work on many different Linuxes today and in the future.
So it would seem that OS ABIs are stable in those OSes that are successful.
Speaking of Windows alone, there are the various calling conventions (pascal, stdcall, cdecl), 16, 32, 64 bits, x86, ARM, ARM64EC, DLLs, COM in-proc and ext-proc, WinRT within Win32 and UWP.
Leaving aside the platforms it no longer supports.
So there are some changes to account for depending on the deployment scenario.
reply