There seems to be a heavy emphasis on explaining high level Rust concepts using parallels in C++ which overall leads to a weaker explanation for most items. Perhaps this should be titled: Effective Rust coming from C++.
This is what it was like to read any Kotlin book for the past few years. The general assumption was, "we all know Java, and we're all using IntelliJ... so this is analogous to....". It's useful for Java developers of course. It's not as useful to those that were new to Android development.
I believe the reasoning here is that it's often easier to teach by analogy. Rust is fairly difficult to approach as, "My First Programming Language". On the other hand, C had to do exactly this back in the day. Every book had to explain the stack and the heap so that pointers would make sense.
> I believe the reasoning here is that it's often easier to teach by analogy.
The problem is less the analogy and more the analogy to C++. Which is fine if you’re targeting C++ devs, and C++ oriented rust guides are certainly researched (I saw queries several times on /r/rust). It’s more problematic if you’re billing the guide as more general.
IMO (and this is certainly not shared by everyone), Rust is best understood as being a better C++. That’s it. It’s the best language for when you want to use a mainstream language to write large systems in native code and can’t tolerate a garbage collector.
Trying to shoehorn Rust into every niche is making the language lose focus.
Saying it's a "better" C++ is not very accurate. It's a very different beast IMO, and not suitable for all applications. There are areas where it shines, and areas where C++ would be a better choice.
If you want to call it 'C++-like' that's fine, there are similarities.
It’s hard for me to imagine starting a new project in C++ today instead of Rust, unless I needed interoperability with the pre-existing C++ ecosystem. What are some examples of areas where C++ is better?
There are other reasons, but having access to the mountain of existing C++ libraries (and C libraries) is no small thing.
The shear number of hours that can be saved by using existing known, well-understood, well-developed libraries and tools is enormous.
It will be another decade or two before Rust hits that point, if it does at all. It just takes time.
Also: Rust is a bit lower-level/aimed more at systems programming and forces thinking more about memory and structure than C++ does. That has advantages but isn't always great for higher-level applications. I can whip out a basic gui app using QT but that would takes ages in Rust.
> There are other reasons, but having access to the mountain of existing C++ libraries (and C libraries) is no small thing.
That's true. But a lot of code has a shelf life.
People used to point to CPAN as a huge benefit for using Perl. Most don't any more; while all that code is still out there, a lot of it doesn't really do much that's useful today. It was built for another time.
Some of the existing C/C++ code will rot in the same way.
I think code that is continually edited and expanded over many years, with lots of changes to requirements, if managed poorly, can have a shelf life.
But there's plenty of older code that will continue to work just fine essentially forever.
I use plenty of older code that hasn't been touched and is fine. I also use libraries that have been continually improved that have been fine. QT isn't perfect but it's been around since '95 and I think that the modern state of it is pretty great overall.
I agree with your general point, but its use case extends beyond that specific case in a few areas. Eg, embedded, where the analogy fails. Rust is a great fit for embedded. More generally, it's a fit for any case where you need fast code, low-level code, bare-metal code, or standalone executable.
The author dedicates a small portion of each section to highlighting analogous concepts in C++, but I don't think C++ -> Rust programmers are the only audience that benefit from this book.
