5 ms·

Writing vectorizable code is certainly important for some use cases, but it’s not relevant for the majority of programming tasks, even in systems/infra programm

Writing vectorizable code is certainly important for some use cases, but it’s not relevant for the majority of programming tasks, even in systems/infra programming. Most things outside of numerical work just aren’t bound by the effective width of the core backend. Rust doesn’t have to solve every problem in order to be useful. The major problem it does solve (relative to C++) is 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, and so on — without requiring a garbage collector. This C++ code, a real mistake I’ve seen in the wild, would be totally impossible to write in Rust without explicitly using the “unsafe” keyword: SomeType* foo() { SomeType x; return &x; } None of this has to do with vectorization, but it’s still important and useful for many tasks. (As an aside: I would be curious to know if there are any languages that make it easier to write auto-vectorizing compilers. Personally I’ve never seen numeric tight loop kernels written without explicit use of architecture-specific intrinsics and/or raw assembly language. But I’ve only worked on that sort of code for at most a few months in my career, so I’d be happy to learn if there’s research in this area.)

jasonzemos 7y ago
> 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.
      - 7y ago

jasonzemos 7y ago

> 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.
    - 7y ago