4 ms·

Sorry to add yet another top-level thread, but my take on this is that, while it is correct that unsafe-blocks are a central and contributing factor to this inc

Sorry to add yet another top-level thread, but my take on this is that, while it is correct that unsafe-blocks are a central and contributing factor to this incident, it is incorrect that languages doing what Rust does fundamentally need unsafe-blocks. As long as Rust both has such an easy way to circumvent the type system, and a desire to supplant C and C++ on the basis of code quality and safety, there will be ready fuel and kindling for these sorts of social conflicts.

steveklabnik 7y ago
What is your alternate proposal?
- lidHanteyk 7y ago
  The proposal that has the most concrete chance of succeeding is probably to formalize some of Miri's behaviors as auditors [0], explicit syntactic annotations which indicate a type/function's willingness to have its source code inspected and have facts proven about its behavior. In terms of quality engineering, the "page of assembly" strategy is the one that I think has the most merit. Write out enough machine-level code to boot the machine and provide an environment for some higher-level language. This should take about a page. Rinse and repeat until the higher-level language is high-level enough for comfort. VPRI supposedly had made this technique work for them. This would cleave Rust into two or more languages, though, and I gather that a big selling point of the language is the ability to compromise and allow many different safety perspectives into a single codebase. I'm not Miyazaki; I can't just tell you that unsafe-blocks were a mistake. But clearly and obviously, to anybody watching who has considered design and implementation of programming languages, they were a mistake. Further, they're the same mistake as Safe Haskell. We keep making this mistake, as a community of designers and theorists, and we need to do better. [0] http://www.erights.org/elang/kernel/auditors/ http://www.erights.org/elang/kernel/auditors/
zozbot234 7y ago
> it is incorrect that languages doing what Rust does fundamentally need unsafe-blocks But they do need those. Even C# has unsafe blocks, and Java has sun.misc.unsafe. It's a rather boring feature actually, the interesting part is what you can assert about safe code, and at what cost.

steveklabnik 7y ago

What is your alternate proposal?

lidHanteyk 7y ago
The proposal that has the most concrete chance of succeeding is probably to formalize some of Miri's behaviors as auditors [0], explicit syntactic annotations which indicate a type/function's willingness to have its source code inspected and have facts proven about its behavior. In terms of quality engineering, the "page of assembly" strategy is the one that I think has the most merit. Write out enough machine-level code to boot the machine and provide an environment for some higher-level language. This should take about a page. Rinse and repeat until the higher-level language is high-level enough for comfort. VPRI supposedly had made this technique work for them. This would cleave Rust into two or more languages, though, and I gather that a big selling point of the language is the ability to compromise and allow many different safety perspectives into a single codebase. I'm not Miyazaki; I can't just tell you that unsafe-blocks were a mistake. But clearly and obviously, to anybody watching who has considered design and implementation of programming languages, they were a mistake. Further, they're the same mistake as Safe Haskell. We keep making this mistake, as a community of designers and theorists, and we need to do better. [0] http://www.erights.org/elang/kernel/auditors/ http://www.erights.org/elang/kernel/auditors/

zozbot234 7y ago

> it is incorrect that languages doing what Rust does fundamentally need unsafe-blocks But they do need those. Even C# has unsafe blocks, and Java has sun.misc.unsafe. It's a rather boring feature actually, the interesting part is what you can assert about safe code, and at what cost.