[kibwen]

On the contrary, I'd say that learning Rust is a fabulous stepping stone to "modern" C++ (much of which served as the philosophical foundation for Rust in the first place). And once you get good enough at Rust that you've internalized the rules regarding memory ownership, you'll be able to instinctively apply those same rules successfully in C++, where the compiler proves fewer things for you.

[neilv]

I appreciate what you're saying, and that there's some truth to that, but I think there's at least two components to good allocation management in C++ (or C, or other memory-unsafe language)...

The first component is conventions and idioms for managing allocations, and Rust will force you into (and support) some good (but nontrivial) ones.

The second component is self-discipline. Look at the long history of vulnerabilities in C and C++ code that are due to carelessness -- of an oops that a programmer made when they knew better.

If what's being considered is Rust as a stepping stone to C++, how much does Rust help with the first component, and is Rust even counterproductive for the second component?

Regarding counterproductive for the second component, you might've seen a conventional practice of grinding the Rust Clippy until the code compiles. I don't know how that affects the development of self-discipline (e.g., maybe some people try to make a practice of being Clippy-free on every compile attempt?), but it seems a reasonable and interesting question to ask.

(I'm not dissing Rust for this. I mostly like Rust, and would be happy to be working in/on it.)

[kibwen]

I'd say that concerns regarding self-discipline are overblown in this case. Experienced Rust programmers aren't simply typing blindly into their editor and hoping that their code will compile. When writing Rust one comes to learn the code that the compiler likes, and strives to write code that is free of compiler errors in the first place. This is itself an expression of self-discipline, except that the discipline comes in the form of compiler errors rather than runtime errors. There's less of a penalty for making an error in Rust than in C++, but that's going to be true regardless of whether one's background is "I already know Rust" or "I don't already know Rust", which is what the parent commenter appears to be concerned about.

[neilv]

> When writing Rust one comes to learn the code that the compiler likes, and strives to write code that is free of compiler errors in the first place.

I suggested that possibility, but is it generally true, or something personally true for you, or are you advocating that it would be good if people did that?

[unrealhoang]

When I started learning Rust and low-level programming (I'm coming from Ruby), spamming/searching for error/fixing code and wait for `cargo build` to turn green was the strategy I used. As I have more experience with Rust I become more and more aware of ownership/lifetime of everything I'm using, the compiler errors appear less and less, most of the time it's typo or mut missing now and not lifetime issues anymore.

So yes, if you work enough with the borrow checker, your brain will form another logical one, and that one you can use for writing C/C++ code. I have much more confident now in learning/writing C/C++ than before I learn Rust, because I feel like I can form a Rust-like design (tree-based, clear ownership/lifetime objects) and put that in using C/C++ syntax.

Definitely recommend using Rust as stepping stone to learn production-grade level C/C++.

[steveklabnik]

I personally think it’s more nuanced than either of these. I do blindly type stuff in, and lean on the compiler to help me. At the same time, as I got more proficient, my initial code is closer to correct and produces far less errors.