4 ms·

Don't really have an axe to grind regarding strict-serializability, serializability, snapshot isolation or whatever. Start at the highest level of consistency a

Don't really have an axe to grind regarding strict-serializability, serializability, snapshot isolation or whatever. Start at the highest level of consistency and consciously step away if you encounter issues. The Postgres default of "Read committed" gives me shivers on the other hand... > If I were to make a concurrent map data structure whose operations are not linearizable and then put it on a library and give it to my users, any user of that library would come back to me and say that my library has a bug. They may not be able to tell me exactly what it is, but they'll understand that there is a bug in it. > However, if I take the same concurrent map data structure, and put in an application and call that application a "Key-Value store" or a "Database" (DBMS) and give it to the typical database users, it seems they may certainly use it for a several decades without ever complaining that this "Database" is not linearizable (or serializable as the DB folks call it). https://concurrencyfreaks.blogspot.com/2020/06/you-say-read-committed-i-say-buggy-code.html https://concurrencyfreaks.blogspot.com/2020/06/you-say-read-...

WJW 4y ago
I like my strictness just as much as anyone else, but this seems like a "works in practice" vs "works in theory" issue to me. Linearizability is just not as important as some people make it out to be. (On a slightly meta level, you can see this happening for a great many issues in programming. Memory safety is undeniably nice, but approximately none of the worlds databases or kernels are written in memory safe languages. Type safety is nice but a huge majority of frontend code is untyped. Don't even get me started on the value of unit testing vs its absence in academic code)
- Gwypaas 4y ago
  > Linearizability is just not as important as some people make it out to be. That's my entire point. Start with strong models and weaken when you decide you need it. Thus rule out entire classes of bugs for 99% of your code and closely scrutinize the 1% with weakened guarantees to know that it works. That is kind of the entire premise behind Rust. Make it extremely visible where the dragons may exist, because you have the key to unlock that door. Regarding memory safety, 70% of CVEs at Microsoft and in Chrome are memory safety bugs. I would say the choice of languages without memory safety is more based on legacy than some kind of insightful choice. https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro... https://security.googleblog.com/2022/03/whats-up-with-in-wild-exploits-plus.html https://security.googleblog.com/2022/03/whats-up-with-in-wil...
  - WJW 4y ago
    > I would say the choice of languages without memory safety is more based on legacy than some kind of insightful choice. You say this as if legacy choices are not some of the most persistent choices that exist in technology. I don't disagree that 70% of CVEs is memory safety related, but still my previous point stands that none of the popular kernels or databases are written in Rust. A new database developer with a bright idea is basically confronted with the choice to either: 1. Write it in C and get it merged into Postgres relatively quickly. (Within the year or so) 2. Write it in Rust and also have to implement the rest of a RDBMS, then have to find a user base. When confronted with that kind of choice, most devs would choose option 1 every time and I can't blame them for that even though I love memory safety.
    - naasking 4y ago
      They'd probably be better off writing a Rust-to-C converter than writing another DB engine.

WJW 4y ago

I like my strictness just as much as anyone else, but this seems like a "works in practice" vs "works in theory" issue to me. Linearizability is just not as important as some people make it out to be. (On a slightly meta level, you can see this happening for a great many issues in programming. Memory safety is undeniably nice, but approximately none of the worlds databases or kernels are written in memory safe languages. Type safety is nice but a huge majority of frontend code is untyped. Don't even get me started on the value of unit testing vs its absence in academic code)

Gwypaas 4y ago
> Linearizability is just not as important as some people make it out to be. That's my entire point. Start with strong models and weaken when you decide you need it. Thus rule out entire classes of bugs for 99% of your code and closely scrutinize the 1% with weakened guarantees to know that it works. That is kind of the entire premise behind Rust. Make it extremely visible where the dragons may exist, because you have the key to unlock that door. Regarding memory safety, 70% of CVEs at Microsoft and in Chrome are memory safety bugs. I would say the choice of languages without memory safety is more based on legacy than some kind of insightful choice. https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro... https://security.googleblog.com/2022/03/whats-up-with-in-wild-exploits-plus.html https://security.googleblog.com/2022/03/whats-up-with-in-wil...
- WJW 4y ago
  > I would say the choice of languages without memory safety is more based on legacy than some kind of insightful choice. You say this as if legacy choices are not some of the most persistent choices that exist in technology. I don't disagree that 70% of CVEs is memory safety related, but still my previous point stands that none of the popular kernels or databases are written in Rust. A new database developer with a bright idea is basically confronted with the choice to either: 1. Write it in C and get it merged into Postgres relatively quickly. (Within the year or so) 2. Write it in Rust and also have to implement the rest of a RDBMS, then have to find a user base. When confronted with that kind of choice, most devs would choose option 1 every time and I can't blame them for that even though I love memory safety.
  - naasking 4y ago
    They'd probably be better off writing a Rust-to-C converter than writing another DB engine.