It has C and C++'s performance without a lot of the footguns. A better type system. The trait system is a nicer way to extend types than C++'s class system (IMO). Generics from the start, instead of absent (C) or added on and still not fully utilized by practitioners (C++, some practitioners get the value, other offices bar using them). The ownership model means that using the lower level concurrency primitives is less likely to have the subtle issues of C and C++. It also means they could avoid encoding a specific concurrency model into the language (like Go or Erlang) and let those be libraries.
Cargo as a standard build system, package manager, and test runner. This makes for a much more coherent development environment than the tire fire that is C and C++'s build, test, and package management story.
Developing tests is much easier than in C and C++, which means many of the packages are actually reasonably well tested (maybe not perfect, but better than the average C or C++ package you might want to incorporate into a project).
Rust has a pretty good module system. C has nothing of the sort, and C++ has a mix of things that can be used similarly (classes, namespaces) and only recently got modules proper in C++20. This helps a lot with organizing your code into a modular structure and then sharing that code with other projects.
Rust can call and be called from C, so there is no tossing anything out. You can integrate Rust into an existing project one file at a time. Move your more critical code into it, and let other code call it. Going back to concurrency, put the part that generates and manages workers (as an example of one model) in Rust and leave the rest of the logic in C or C++. Gradually migrate the worker logic into Rust, or not. Perhaps it's a library that you don't control or don't want to change.
Some things aren't pretty or aren't clear. For instance, str and String are pretty confusing for new users. But the compiler will catch these for you. Speaking of, actually decent compiler warnings and errors. Often with potential fixes included, which usually do what you want.
In summary: Fewer footguns, better quality of life components, better language features in some areas (type system, modules, in particular), no performance hit (or no major performance hit) compared to other options for languages attempting to offer improved safety (where safety could be along many dimensions).
Depends what you mean I guess. You can certainly write code that doesn't create more generic structs, and needing to create more generic structs when writing simple application plumbing code is relatively rare. On the flip side you also certainly want to use stdlib (and third party) libraries and instantiate generic structs they define. For example a list of T objects is most commonly stored in a Vec<T> where T is a generic, or for a builtin example a fixed sized array is a `[T; N]` where both T and N are generic. There's also approximately no reason to avoid generics.
All in all the frequency of use of generics is pretty similar to languages like C++ or Scala.
Perhaps Rust can be the language where I force myself to get used to them. In C++ there are stilly plenty of alternatives to not having to use templates. The reason I ask is I've preferred not to use them because I find them slightly more demanding to read.
I think that's just a personal bias I need to get over.
Yeah you're not alone. Have you used concepts at all yet? Rust's generics are similar to, but different than, C++ templates generally; concepts is the closest thing C++ has to them. That being said, even when you understand them, you can create some monstrosities, just like C++.
To connect it back to your original questions, Rust relies heavily on generics because if you want runtime performance, but you also want safety, you pretty much need ways to evaluate safety at compile time, rather than runtime, so you don't have the overhead of runtime checks. This basically implies generics need to exist and be used heavily.
Any time. One last tiny bit of overview: templates can currently do a bunch of things that Rust generics can’t. Some of these are things that Rust will be adding in the future, some are not, and some are uncertain. So there’s a lot of parallels but some folks who are very invested in templates say they don’t want to move to Rust yet because we’re missing things they desire.
Cargo as a standard build system, package manager, and test runner. This makes for a much more coherent development environment than the tire fire that is C and C++'s build, test, and package management story.
Developing tests is much easier than in C and C++, which means many of the packages are actually reasonably well tested (maybe not perfect, but better than the average C or C++ package you might want to incorporate into a project).
Rust has a pretty good module system. C has nothing of the sort, and C++ has a mix of things that can be used similarly (classes, namespaces) and only recently got modules proper in C++20. This helps a lot with organizing your code into a modular structure and then sharing that code with other projects.
Rust can call and be called from C, so there is no tossing anything out. You can integrate Rust into an existing project one file at a time. Move your more critical code into it, and let other code call it. Going back to concurrency, put the part that generates and manages workers (as an example of one model) in Rust and leave the rest of the logic in C or C++. Gradually migrate the worker logic into Rust, or not. Perhaps it's a library that you don't control or don't want to change.
Some things aren't pretty or aren't clear. For instance, str and String are pretty confusing for new users. But the compiler will catch these for you. Speaking of, actually decent compiler warnings and errors. Often with potential fixes included, which usually do what you want.
In summary: Fewer footguns, better quality of life components, better language features in some areas (type system, modules, in particular), no performance hit (or no major performance hit) compared to other options for languages attempting to offer improved safety (where safety could be along many dimensions).