by oherrala on 11/18/18, 11:22 AM with 25 comments
by kibwen on 11/18/18, 2:02 PM
I wouldn't quite put it like that. I can't speak to SPARK, but Rust absolutely doesn't want to displace or discount the value of tools and processes--it wants to augment them.
Rust positions itself as one layer in a defense-in-depth strategy; that's the reason why Rust, despite striving to provide strong memory safety guarantees, still compiles programs with RELRO, NX, ASLR, PIE, basically whatever binary-level mitigations it can get its hands on.
As far as tools go, the Rust compiler is viewed as just the first tool of many. Rust recently changed the default allocator of Rust programs to be the system allocator rather than jemalloc (the system allocator was already the default on some platforms, like Windows), in order to (among other reasons) support Valgrind out of the box. And I don't know the current level of support for these, but Rust does eventually seek to support LLVM's various sanitizers: asan, tsan, ubsan, msan, etc. (currently I think these might work primarily on 64-bit Linux). Rust is also developing external tools of its own; see for example this blog post series from Ralf Jung about creating a tool to dynamically check the validity of unsafe code in Rust programs, with the eventual goal of having a formally-proven model: https://www.ralfj.de/blog/2018/11/16/stacked-borrows-impleme...
As for processes, one of the impetuses for locking undefined behavior behind the `unsafe` keyword was to better focus developer processes on writing and reviewing code. For example, Servo has a bot that comments on any PR that touches a file containing the `unsafe` keyword. In an organization using Rust, I would expect any first-time Rust programmers to be disallowed from checking in code using the `unsafe` keyword until they get a handle on the language.
by sidcool on 11/18/18, 2:00 PM
by thramp on 11/18/18, 4:16 PM
by steveklabnik on 11/18/18, 3:30 PM
by Animats on 11/18/18, 9:37 PM