3 ms·

> 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 ne

> 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 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.