Hacker News Reader

> 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.)

> 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-upda...

and clang's is progressing nicely : https://llvm.org/devmtg/2019-04/slides/TechTalk-Horvath-Impl...

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.

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

Thanks; you’re right, of course. I think I was slightly misinterpreting the meaning of “function-local” when I originally wrote that.

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.

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

> 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."

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