TBH, I find the whole premise a bit silly. The one use case the original video talks about there this might be a good idea is when you have something like a MonsterId(String), and argues for MonsterId(Arc) instead - which I think is an anti-pattern. Use MonsterId(usize) and it becomes far cheaper to clone than even an Arc. There is no need to lug around strings as ids - which are presumably going to be used to look up values in a hashmap or similar (which again, I would suspect it is faster to has a usize than a string of any type).
Most of the rest of the time cloning a string is not a huge issue or if it is &str is often good enough. I find it rare that you would ever need the clone performance and multiple ownership of a Arc.
There are also crates like smallstring, smallstr etc, that are stack allocated strings up to a certain limit before they start allocating. Which would be worth a look at and see how they preform compared to Arc or String. Since most things I bet they were using Strings for would fit inside these types just find without the extra allocation.
It is a neat trick to have in your toolbag - but not the first thing I would jump for when dealing with strings.
The main use case is "uuid," but those can be represented as 128-bit integers instead of character sequences if cloning is a concern. This emphasizes your point, usually there's a more obvious, good enough solution to performance issues than moving a string to an Arc.
It is a neat trick, and something I love reading about, but I would very much expect a lengthy comment in the code if someone does this in practice because it is not obvious at all.
The main use case is “uuid,” but those can be represented as 128-bit integers
Oh man. I've seen so much software that treats UUIDs as strings internally. I've also seen things like IPv4 addresses being used in dotted notation as strings, and then the developers asking themselves why calculating "is this addr in this subnet" is so complicated.
I blame it on many people only learning high level scripting languages.
which are presumably going to be used to look up values in a hashmap or similar (which again, I would suspect it is faster to has a usize than a string of any type).
Yeah, for any primitive types, you can just use the value itself as the hash value here. So, effectively a noop. I assume, Rust's implementation makes use of this...