4 ms·

Frama-C's analysis is neither sound nor complete and it's way way harder to set up and use than Rust.

pjmlp 6y ago
As someone that has enough C and C++ experience going back to 1992, worked at CERN and Nokia in very complicated C++ codebases and still has issues with the borrow checker and when to annotate what, I beg to differ how easy it is to use Rust, although I do conceed it has gotten much better.
- Jweb_Guru 6y ago
  I am well aware of your opinions on this matter. None of what you just said has anything to do with Frama-C. You can't throw that out there as a Rust alternative (which, as I noted, it is not, or at least not a complete one) and then compare how easy "vanilla C++" is compared to Rust (like I said, I disagree with you on that, but it's not even relevant here). The truth is that for people who care about safety (as I know you and I do), want to use an unmanaged language (for whatever reason), and don't want to use Ada (no accounting for taste, I guess), the "correct" comparison is C and C++ with a load of static analysis tools that don't quite work, miss plenty of bugs, enable dynamic protection that slows down your program, are not easy to install, and can be terribly noisy when not configured extensively for your project... vs. Rust which works out of the box, has the analysis integrated into the typechecker, has a simple installation and upgrade process, and catches everything. In that competition, Rust wins every time.
  - pjmlp 6y ago
    Almost fully agree, just the ergonomics are fully there and while static analysis tools aren't fully there, nor ever will, as you well point out, the likes of Google and Microsoft seem quite minded to bring Rust into C++, despite their ongoing adoption of Rust. As the latest posts from Visual C++ seem to imply, https://devblogs.microsoft.com/cppblog/new-safety-rules-in-c-core-check/ https://devblogs.microsoft.com/cppblog/new-safety-rules-in-c... https://cppcon2020.sched.com/event/e7C0/introducing-microsofts-new-open-source-fuzzing-platform https://cppcon2020.sched.com/event/e7C0/introducing-microsof... Because the language alone isn't enough, the existing eco-system and tooling also plays a big role. Since we are speaking about games here, C++ just hit the jackpot with GPGPU programming, even though other languages are also supported in PTX and SPIR-V. So I am actually curious how far the companies with seat at ISO C++ are actually going to adopt Rust on their platforms, versus briging Rust learnings into C++.
    - Jweb_Guru 6y ago
      Microsoft, sure--nobody has worked harder than they have to try to make C++ safer. And there are other big companies seriously investing in making C++ safer (e.g. Facebook, bad as they are otherwise). But I've also talked to many of the researchers actually working on these projects--they'll freely tell you how hard the task is and how impossible it is to really apply Rust's straightforward solutions to the massive existing legacy of C++ code. And let's be honest--if your tool requires people to rewrite everything anyway, they might as well choose Rust, so it's not acceptable for your tool to only work on modern stuff, or require annotations everywhere you use std::string_view, etc. And I should be very clear that this is quite specific to C and C++. Ada, for example, has been able to adopt solutions from Rust with ease, and even add some interesting improvements, because the safe subset of their language was conservative and the borrow checker allows them to extend it. So I'm not saying other languages cannot copy Rust, it's very much specific to unsafe by design languages like C++. They're trying to make their existing codebases safer, and I think that's great, but unless there's a massive breakthrough in the next few years these aren't going to be general purpose solutions and they are definitely not going to be close to sound. For example, pretty much everything I'm aware of for C++ that tries to do memory safety, punts on thread safety, because it's just virtually impossible with all the other stuff going on; many of them punt on recursive function calls, and a bunch don't even do anything but very basic interprocedural analysis, focusing all their energy on "local" intraprocedural bugs that are much easier to catch. The tools would just be too noisy to be useful otherwise. As for Google... they resisted investing in static analysis tools for years and I don't take them seriously at all when they talk about this sort of thing.
      - pjmlp 6y ago
        Google is at least serious on Android with all the mitigations that have been added, inclusive being able to write drivers in Java (as per Project Treble), and it is thanks to them that Linux no longer uses VLAs. But for example, in spite of using Rust on ChromeOS, Fuchsia and now thinking of introducing Rust on Android 12+, there are no plans to expose it in any of the OS SDKs for userspace applications.

As someone that has enough C and C++ experience going back to 1992, worked at CERN and Nokia in very complicated C++ codebases and still has issues with the borrow checker and when to annotate what, I beg to differ how easy it is to use Rust, although I do conceed it has gotten much better.

Jweb_Guru 6y ago
I am well aware of your opinions on this matter. None of what you just said has anything to do with Frama-C. You can't throw that out there as a Rust alternative (which, as I noted, it is not, or at least not a complete one) and then compare how easy "vanilla C++" is compared to Rust (like I said, I disagree with you on that, but it's not even relevant here). The truth is that for people who care about safety (as I know you and I do), want to use an unmanaged language (for whatever reason), and don't want to use Ada (no accounting for taste, I guess), the "correct" comparison is C and C++ with a load of static analysis tools that don't quite work, miss plenty of bugs, enable dynamic protection that slows down your program, are not easy to install, and can be terribly noisy when not configured extensively for your project... vs. Rust which works out of the box, has the analysis integrated into the typechecker, has a simple installation and upgrade process, and catches everything. In that competition, Rust wins every time.
- pjmlp 6y ago
  Almost fully agree, just the ergonomics are fully there and while static analysis tools aren't fully there, nor ever will, as you well point out, the likes of Google and Microsoft seem quite minded to bring Rust into C++, despite their ongoing adoption of Rust. As the latest posts from Visual C++ seem to imply, https://devblogs.microsoft.com/cppblog/new-safety-rules-in-c-core-check/ https://devblogs.microsoft.com/cppblog/new-safety-rules-in-c... https://cppcon2020.sched.com/event/e7C0/introducing-microsofts-new-open-source-fuzzing-platform https://cppcon2020.sched.com/event/e7C0/introducing-microsof... Because the language alone isn't enough, the existing eco-system and tooling also plays a big role. Since we are speaking about games here, C++ just hit the jackpot with GPGPU programming, even though other languages are also supported in PTX and SPIR-V. So I am actually curious how far the companies with seat at ISO C++ are actually going to adopt Rust on their platforms, versus briging Rust learnings into C++.
  - Jweb_Guru 6y ago
    Microsoft, sure--nobody has worked harder than they have to try to make C++ safer. And there are other big companies seriously investing in making C++ safer (e.g. Facebook, bad as they are otherwise). But I've also talked to many of the researchers actually working on these projects--they'll freely tell you how hard the task is and how impossible it is to really apply Rust's straightforward solutions to the massive existing legacy of C++ code. And let's be honest--if your tool requires people to rewrite everything anyway, they might as well choose Rust, so it's not acceptable for your tool to only work on modern stuff, or require annotations everywhere you use std::string_view, etc. And I should be very clear that this is quite specific to C and C++. Ada, for example, has been able to adopt solutions from Rust with ease, and even add some interesting improvements, because the safe subset of their language was conservative and the borrow checker allows them to extend it. So I'm not saying other languages cannot copy Rust, it's very much specific to unsafe by design languages like C++. They're trying to make their existing codebases safer, and I think that's great, but unless there's a massive breakthrough in the next few years these aren't going to be general purpose solutions and they are definitely not going to be close to sound. For example, pretty much everything I'm aware of for C++ that tries to do memory safety, punts on thread safety, because it's just virtually impossible with all the other stuff going on; many of them punt on recursive function calls, and a bunch don't even do anything but very basic interprocedural analysis, focusing all their energy on "local" intraprocedural bugs that are much easier to catch. The tools would just be too noisy to be useful otherwise. As for Google... they resisted investing in static analysis tools for years and I don't take them seriously at all when they talk about this sort of thing.
    - pjmlp 6y ago
      Google is at least serious on Android with all the mitigations that have been added, inclusive being able to write drivers in Java (as per Project Treble), and it is thanks to them that Linux no longer uses VLAs. But for example, in spite of using Rust on ChromeOS, Fuchsia and now thinking of introducing Rust on Android 12+, there are no plans to expose it in any of the OS SDKs for userspace applications.