3 ms·

> Explicit compile-time tracking and enforcement of the scope of object validity, preventing (or at least making more unlikely) a class of bugs including use-af

> Explicit compile-time tracking and enforcement of the scope of object validity, preventing (or at least making more unlikely) a class of bugs including use-after-free, uninitialized reads, buffer overflows, dangling pointers. Why does an entirely new syntax have to be invented from the ground up to solve this problem? Does C-like syntax not adequately inform a compiler that wants to implement something like Rust's borrowing? It appears to work for `std::unique_ptr` and `std::move` semantics. It doesn't appear that Rust's syntax conveys any order of magnitude more information. Minor augmentations to C/C++, taking it some other direction which fixes whatever shortcomings for next-generation static analysis tools can be the focus of effort. I don't see why Rust first has to invent the universe. Here's an example of overhead effort required by Rust: https://github.com/rust-vmm/kvm-bindings https://github.com/rust-vmm/kvm-bindings. This has already been implemented in C and distributed with most operating systems. Why wrap it? Now when KVM gets new features Rust has to also update its wrapper interface too. Isn't that just a propagation delay?

umanwizard 7y ago
> Why does an entirely new syntax have to be invented from the ground up to solve this problem? I don’t know. I’m not on the core Rust team. Whether it’s theoretically possible to write static analyzers that implement Rust-like guarantees in C-like languages seems a bit irrelevant to me, since in the real world, none actually exist. Rust does. I will happily continue using Rust, and happily reevaluate that choice if these next-generation static analyzers ever materialize. (Also: Personally, to me, understanding rust syntax is actually much easier than trying to remember what && means in various contexts, the difference between std::move and std::forward, the difference between decltype(foo) and decltype((foo)), and various other C++ gotchas. But YMMV.)
- jcelerier 7y ago
  > Whether it’s theoretically possible to write static analyzers that implement Rust-like guarantees in C-like languages seems a bit irrelevant to me, since in the real world, none actually exist. Rust does. actually, MSVC has a lifetime tracker for a year now : https://devblogs.microsoft.com/cppblog/lifetime-profile-update-in-visual-studio-2019-preview-2/ https://devblogs.microsoft.com/cppblog/lifetime-profile-upda... and clang's is progressing nicely : https://llvm.org/devmtg/2019-04/slides/TechTalk-Horvath-Implementing_the_C++_Core_Guidelines_Lifetime.pdf https://llvm.org/devmtg/2019-04/slides/TechTalk-Horvath-Impl...
  - umanwizard 7y ago
    Both of those are much newer than Rust. So it appears Rust was valuable after all, even if all it did was influence C++ static analysis developers! I will also point out that these are still much less than what Rust offers — read through the list of caveats in the MSVC post. Or the fact that “analysis is only function-local” in Clang... Oh, and for these to catch everything you would need to only depend, transitively, on things that also used them. Just like in Rust you need to only depend transitively on things that don’t abuse `unsafe`, but that seems less unreasonable to me.
    - steveklabnik 7y ago
      > Or the fact that “analysis is only function-local” in Clang... This is not inherently a problem; Rust's analysis is also function-local, it's actually a design goal. That said, you're 100% right at the issues here; this does not guarantee memory safety, it is far less than what Rust provides. That said, I'm happy it exists; anything that makes stuff better is a win.
      - umanwizard 7y ago
        Thanks; you’re right, of course. I think I was slightly misinterpreting the meaning of “function-local” when I originally wrote that.
zaxcellent 7y ago
As someone who wrote a precursor to that code (I work on crosvm), any language other than C has to write binding code for KVM (or any kernel interface for that matter). Are you suggesting that the only language that should get to use KVM is C (and other languages that can consume C headers)? Additionally, when KVM gets new features, the hard part will not be adding more bindings to that crate; it will be utilizing that feature, which would have to happen in any langauge.
- jasonzemos 7y ago
  > Are you suggesting that the only language that should get to use KVM is C What I'm asking is why Rust can't read the C header. I know that sounds like a ridiculous question, but I'm asking it honestly and seriously.
imtringued 7y ago
>This has already been implemented in C and distributed with most operating systems. Why wrap it? Because the wrapper will offer Rust features that C failed to implement for almost half a century.
steveklabnik 7y ago
> Does C-like syntax not adequately inform a compiler that wants to implement something like Rust's borrowing? It appears to work for `std::unique_ptr` and `std::move` semantics. It does not. Note that Rust's move semantics are different than C++'s, Rust has what C++ folks call "destructive move."

umanwizard 7y ago

> Why does an entirely new syntax have to be invented from the ground up to solve this problem? I don’t know. I’m not on the core Rust team. Whether it’s theoretically possible to write static analyzers that implement Rust-like guarantees in C-like languages seems a bit irrelevant to me, since in the real world, none actually exist. Rust does. I will happily continue using Rust, and happily reevaluate that choice if these next-generation static analyzers ever materialize. (Also: Personally, to me, understanding rust syntax is actually much easier than trying to remember what && means in various contexts, the difference between std::move and std::forward, the difference between decltype(foo) and decltype((foo)), and various other C++ gotchas. But YMMV.)

jcelerier 7y ago
> Whether it’s theoretically possible to write static analyzers that implement Rust-like guarantees in C-like languages seems a bit irrelevant to me, since in the real world, none actually exist. Rust does. actually, MSVC has a lifetime tracker for a year now : https://devblogs.microsoft.com/cppblog/lifetime-profile-update-in-visual-studio-2019-preview-2/ https://devblogs.microsoft.com/cppblog/lifetime-profile-upda... and clang's is progressing nicely : https://llvm.org/devmtg/2019-04/slides/TechTalk-Horvath-Implementing_the_C++_Core_Guidelines_Lifetime.pdf https://llvm.org/devmtg/2019-04/slides/TechTalk-Horvath-Impl...
- umanwizard 7y ago
  Both of those are much newer than Rust. So it appears Rust was valuable after all, even if all it did was influence C++ static analysis developers! I will also point out that these are still much less than what Rust offers — read through the list of caveats in the MSVC post. Or the fact that “analysis is only function-local” in Clang... Oh, and for these to catch everything you would need to only depend, transitively, on things that also used them. Just like in Rust you need to only depend transitively on things that don’t abuse `unsafe`, but that seems less unreasonable to me.
  - steveklabnik 7y ago
    > Or the fact that “analysis is only function-local” in Clang... This is not inherently a problem; Rust's analysis is also function-local, it's actually a design goal. That said, you're 100% right at the issues here; this does not guarantee memory safety, it is far less than what Rust provides. That said, I'm happy it exists; anything that makes stuff better is a win.
    - umanwizard 7y ago
      Thanks; you’re right, of course. I think I was slightly misinterpreting the meaning of “function-local” when I originally wrote that.

zaxcellent 7y ago

As someone who wrote a precursor to that code (I work on crosvm), any language other than C has to write binding code for KVM (or any kernel interface for that matter). Are you suggesting that the only language that should get to use KVM is C (and other languages that can consume C headers)? Additionally, when KVM gets new features, the hard part will not be adding more bindings to that crate; it will be utilizing that feature, which would have to happen in any langauge.

jasonzemos 7y ago
> Are you suggesting that the only language that should get to use KVM is C What I'm asking is why Rust can't read the C header. I know that sounds like a ridiculous question, but I'm asking it honestly and seriously.

imtringued 7y ago

>This has already been implemented in C and distributed with most operating systems. Why wrap it? Because the wrapper will offer Rust features that C failed to implement for almost half a century.

steveklabnik 7y ago

> Does C-like syntax not adequately inform a compiler that wants to implement something like Rust's borrowing? It appears to work for `std::unique_ptr` and `std::move` semantics. It does not. Note that Rust's move semantics are different than C++'s, Rust has what C++ folks call "destructive move."