It seems like over time, a lot of that was replaced with C++-style syntax and semantics. Presumably to make the language appeal more to C++ devs
Implementation-wise they're the same trick as C++, monomorphization.
Stylistically they're not very like either, however the effect is more like C++ because Rust idiomatically prefers to constrain functions not types so e.g. it's fine to talk about HashMap<f32, f32> a hypothetical hash table of floating point numbers mapped to other floating point numbers - even though we can't use such a type because if we try to insert into it we'll be told that insert requires its key parameter to implement Eq and Hash, which f32 doesn't because of NaN.
In both C++ and Java as I understand it these constraints live on the type not the functions associated with that type, although C++ does not have the same constraint here and is perfectly willing to try to make a hash table of floats... but where a constraint lives on a function in C++ it would behave similarly to Rust due to SFINAE - the function won't match so your diagnostics say there's no such function, probably worse diagnostics than Rust but that's par for the course in C++.
My Ruby claim doesn't hold much weight either if we're talking about the actual implementation.
C++ templates look like an entirely new language within the language.
Rust and Java make generics fit within the aesthetics and ergonomics of the language.
If anything feels "bolted on" to Rust, it's proc macros and (to a lesser degree) async.
It doesn't feel like very much, but now that you spell it out I guess I do see it.