3 ms·
> I tend to store references to other objects using indices instead of pointers/references anyway, so the borrow checker isn't really that important for me. C+
by exDM69 4y ago
> I tend to store references to other objects using indices instead of pointers/references anyway, so the borrow checker isn't really that important for me.
C++ references only help you with null pointers and they are a pain in the ass to try to store as a member in a struct with all the weirdness regarding operator=.
C++ references do not help you with use-after-free, accidental concurrent modification or container/iterator invalidation.
E.g. consider the following C++ application:
std::vector<int> v = { 1, 2, 3 };
int& ref = &v[2];
v.push_back(4);
ref = 123; // this will crash if vector is resized by push_back
You're not going to reproduce this bug in Rust (without unsafe), the program will not compile.
As individuals we can deal with these invisible contracts that are everywhere in C++ (and C) programming. But this kind of discipline does not scale to bigger teams.
I kinda agree with you about the "power" of C++ templates vs. Rust generics when it comes to compile time metaprogramming. But for generic programming Rust's traits are very practical and powerful, and with C++ still lacking concepts it's really no match.
You mention one of Rust's generics' biggest pain points: it does not work at all when trying to implement functions that work with i32 and i64, or f32 vs f64, let alone f32x4 vs. f64x4 SIMD vectors. For comparison: Haskell has "Integral" and "Floating" type classes (traits) for this, but Rust for some reason does not.
FFI is painful with every language, including C++ (for C libraries that don't work well w/ C++ idioms). My experience with Rust FFI and bindgen has been excellent. It auto-generates Rust modules from C headers and even converts doxygen comments to Rustdoc. It was about as easy to build a Rust project with some in-house C libraries than it would've been to write a C or C++ program using them with all the CFLAGS+=-Ipath/to/headers and Makefiles I would've had to deal with.
Finally, from a seasoned professional C++ programmer... Rust's tooling blows C++ out of the water. A reasonable build system, linters, API docs, LSP, autoformatting, modules (no more header files). And especially C++'s dysfunctional dependency management is just plain awful (single header libraries or apt-get or whatever aren't a substitute).
With a few decades of C++ experience under my belt, I've found Rust to be a huge leap forward on almost all aspects (but not without its pain points).
- cyber_kinetist 4y ago> C++ references do not help you with use-after-free, accidental concurrent modification or container/iterator invalidation. Maybe I didn't express this clearly enough, but I don't use C++ pointers or references to store something that is more than just temporary, I usually go for indices instead. You should read the "Handles are the better pointers" article (https://floooh.github.io/2018/06/17/handles-vs-pointers.html https://floooh.github.io/2018/06/17/handles-vs-pointers.html) to understand a bit more of what I'm saying. > with C++ still lacking concepts it's really no match. I thought C++ already had concepts in C++20? (Though I honestly haven't got that much use for it, and I still use C++17 since I want to wait a bit until compiler implementations get mature). > Rust's tooling blows C++ out of the water. Agree with Rust's toolings being more polished than its C++ counterparts. I like that Rust has Cargo and also its own build.rs which you can code your custom build scripts in the same language. I also agree that Rust modules are much better than C++ headers (although modules are in C++20, I feel it's already a bit too late when so much existing code hasn't been written for it) The last time I looked at IDE support with Rust it wasn't that great, but that was quite some years ago so things might have changed a lot.
- ncmncm 4y agoYes, C++20 has concepts and modules, the latter still finding its way into production compilers. The story around promoting Rust over C++ has aged badly. Parroting arguments that seemed persuasive in 2015, when most people had not even got C++11, taints your argument. People coding modern C++ don't spend time on memory errors, so promoting that detail of Rust makes you seem out of touch, and other statements doubtful. C++ has got markedly more powerful of late, in ways not matched in Rust. This remark, "FFI is painful with ... C++" is frankly nothing short of bizarre. To win over people coding modern C++, you will need to explain how giving up the powerful features C++ programmers are accustomed to using, but cannot in Rust, will make a better experience anyway. You might need to learn something about those features to have something to say.
- kaba0 4y agoI find your comment quite arrogant, there was really no need to call out the parent poster’s knowledge, especially when he/she only gave some counterexamples. Also, modern C++’s move/copy semantics are exactly what Rust enforces at a language level, instead of only making it a “suggestion”.