Shouldn't that be the A then? Since the network partition is still there but availability is non-guaranteed.

Yes, definitely. Good point (I was knee jerk assuming the A is always chosen and the real “choice” is between C and P).

https://tqdev.com/2024-the-p-in-cap-is-for-performance is a really interesting take on this as a response to https://blog.dtornow.com/the-cap-theorem.-the-bad-the-bad-th... - essentially, the only way to get CA is if you're willing to say that every request will succeed eventually, but it might take an unbounded amount of time for partitions to heal, and you have to be willing to wait indefinitely for that to happen. Which can indeed make sense for asynchronous messaging, but not for real-time applications as we think about them in the modern day. In practice, if you're talking about CAP for high-performance systems, you're choosing either CP or AP.

Well, P isn't really much of a choice, I don't think you can opt out of acts of god.

You can design to minimize P, though. For instance, if you have all the services running on the same physical box, and make people enter the room to use it instead of over the Internet, "partition" becomes much less likely. (This example is a bit silly.)

But you're right, if you take a broad view of P, the choice is really between consistency and availability.

Yes. P is kinda fundamental to your setup.

For example, running S3 locally or not.

Pardon my naivety but why was Typescript chosen as the interface for writing transactional workflows? I can't help but think that a backend language that is more popular for those use-cases would be more relevant.

Maybe the idea is that those who are using those other languages may have other workarounds already?

The overlap for the target audience of TypeScript and "serverless" systems seems much larger than the overlap of the target audience of "backend languages" and "serverless"

I think the naivety lies in underestimating how many backend systems are written in Typescript, and how large of the developer population knows / uses TS.

In either sense, its alot.

(Aside: The backend has plenty of bad languages. For example Python is considered a backend language but is considerably worse than most languages in speed, ergonomics, transitive dependencies, and so on... )

It's a lot but Java is still king. The SV bubble seems to forget just how dominant Java is in backend software (well until they get a job at FANG and realise Java never left the building).

Is there data to support this viewpoint? I've heard it often, but it always seems to lean on anecdata or caveats that the concrete datasets out there have blind spots (which is plausible, but certainly not a given). And those concrete datasets don't usually tend to put Java near the top for professional usage, or any metric for that matter.

Raw popularity is not the only parameter.

Toolchain weight, integration cost, ease of building DSLs, error message quality ... All those things matter when choosing a language to be embedded as a DSL into another system.

True. Though the last time Stonebraker tried this (VoltDB) they did lean on Java for DB side custom logic.

I wasn't really making a comment on that though but rather on overall popularity of TS vs Java, which is mostly just about the influence of the echo chamber and how that distorts peoples perception of what is out there.

The eco chamber is real but it cuts both ways: if you want your product to be successful you need a first wave of adopters and their echo chamber will shape your product through their feedback.

Once your product reaches a wider audience you may notice that the balance is different but that doesn't mean that if you had chosen what makes sense for the wider audience (e.g. java) in the first iteration you'd be necessarily at a better place now. Perhaps you wouldn't never get to the place of worry how to please the masses because you product wouldn't have had any success in the first selection environment