Hacker News Reader

> Rust has one really outstanding feature -- a borrower checker that makes it memory safe. Adding that to C++ would be a compatibility-breaking change. So then, while they were at it, they changed lots of other things. It's a whole different language, separate syntax, generics that work differently than templates, different standard library, etc.

> I understand the desire to make changes. Many of the changes are improvements, and C++ can be ugly. But it's the devil we know. A version of it with the minimum necessary changes to add a borrow checker would have me using it already, and I expect I am not the only such person.

What you say would make sense if Rust were based on C++. I've never heard anyone say that.

I was under the impression that Rust is a derivative of ML, and (to me, at least) it looks very much like StandardML or OCaml with a borrow checker.

(I don't know C++, so I can't personally comment on how similar or different it is from Rust)

It's sorta kinda both. The original implementation was in OCaml, and many of the early developers were big ML fans. But we also tried to keep syntax more C-like, overall.

"It's a C-like OCaml" was how Rust was originally described to me, when I first heard of it.

Moreover, it doesn't matter what it is based on, it matters what it is trying to displace.

I am not really even criticizing Rust. Let it be what it is. Python isn't C++ either. All I'm saying is that if the goal is to increase the number of people using memory safe languages, adding a borrow checker to C++ would serve that goal.

(Also, I would really like to have a language with both a borrower checker and actual C++ templates.)

What do you prefer about templates?

(And yes, I fully support making C++ safer too; the GSL is as close as we're going to get, probably.)

Template metaprogramming, variadic templates, integers as template parameters, etc. Even better would be constexpr user types as template parameters.

How about a language that embraces Turing-complete template metaprogramming as a thing to design in on purpose rather than something discovered after the fact to be more useful than anticipated. Have the utility without the ugly.

Cool, thanks! I think you'll be happy with Rust eventually; a lot of this is coming, likely this year. It's on the roadmap, though that has to be approved first. (The thing that isn't yet is variadrics, not sure when that'll happen.)

(And the reason it's taking such a while is that we are actually doing that...)

They are working on it. The analogue to the borrow checker in C++ is called the "lifetime profile checker" and (an incomplete version) is included in MS Visual C++, but last time I checked (in January) it seemed to still have too many false positives to be practical.

In the mean time, I think "the minimum necessary changes" to achieve memory and data race safety is to replace all your unsafe C++ elements (pointers, arrays, vectors, string_views, etc.) with compatible substitutes from the SaferCPlusPlus library [1]. You don't even need to replace them all at once. You can replace them incrementally and your code will continue to compile and run throughout the process. And where needed, maintain maximal performance as well [2].

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

[2] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

Different standard library is kind of unavoidable because you need standard library interface understood by borrow checker.

That's the compatibility-breaking part. Doesn't mean the replacement function or object can't have the same name, purpose, time complexity, etc.

You could potentially even continue to support the existing ones but regard them as unsafe and have the compiler warn if they're used.

Microsoft already does that with their SAL annotations.

https://docs.microsoft.com/en-us/visualstudio/code-quality/u...

Which they are extending to also support their C++ lifetime checker.