We steer away from strings in the runtime at all times since they are so problematic. A single string has no real impact on anything, but since they are so convenient for us humans they tend to rapidly populate the memory. In the worst case, you can end up with the most problematic of perf issues; when a lot of things take a little time each, summing up to a problem. It takes a really long time to fix issues like that. This is why we deliberately don’t support strings, to guide users towards working with hashes which are free from these issues.
The exception is obviously as you stated, when you want to display information to the player. The information comes from two sources, static (which often becomes localised and fits well in a string library) or dynamic from web services or other players. In the dynamic situation it still makes sense to keep these things in a separate data store and the thing to display stuff has a key into that store (like @britzl’s example). You might want to be able to supply place holder info in the absense of responses, etc.
9 Likes