3 ms·

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 imp

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

by WJW 4y ago

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.