I support the default on consistence the way you posed it. Main reason is safe-by-default construction has proven more effective for average programmer over decades. The other approach caused many disasters.
Meh, this is just pr, nothing is safe-by-default. It's not actually true that people eventually assume strong consistency, because eventual consistency forces certain stricter way of thinking about the state and time, kind of functional, you just can't escape it. It's strong consistency that lets you get sloppy, while making you forget how not simple it is. It only exists inside the system and if you have clients from the outside of the system, like web browsers, you don't have two phase commit protocol on a button click there, so you have to resort to that same functional way of thinking to at least try not to confuse anyone on retry, but it's clearly not the case in the wild. It's just too complex.
I don't think anyone goes back from eventual consistency. It's more appropriate for this asynchronous world, easier and more reliable.
Google disagreed on that last part. Their bright engineers kept screwing up with eventual consistency. It's why they built Spanner in the first place followed by F1. So did customers of FoundationDB and Cochroach despite free solutions available for eventual consistency.
So, Im not seeing it so clear cut in favor of eventual consistency.
Google never did or bothered to do much work on eventual consistency, they cannot possibly have any experience with it. CRDTs didn't came from them. And you know very well that customers do not care about any of this.
Their cloud storage said eventually consistent for apps needing a lot of performance when I looked into it. A quick Google on the offerings show pages describing what tradeoffs are available for customers with each option. So, they not only know about it: they implemented it as a product feature. Their internal stores were strongly-consistent with high performance except AdWords on MySQL. That got moved to F1 for strongly-consistent high-performance. Spanner, which F1 uses, then got offered to cloud customers.
After re-reading the F1 paper, my mistake seems to be thinking they relied on eventually-consistent stuff internally. It appears that was just an option for 3rd party developers in their cloud products. Thanks for the peer review as I found some more stuff double checking. :)
