Yes, OK, this is a good place to add some data to what seems to be a condemnation of string types for storage at all.

If we want the smallest possible file size, and the fastest possible read times, then binary files are the way to go. But debugging them is a nightmare, and when I write binary files I also always end up having to write tools to help me visualize them.

Text files are larger, but I can read them. And I can hand-edit them. And sometimes, if they get corrupted, I have half a chance of fixing them. This is why, even though they're obsessed with doing arcane things in the name of performance, UNIX developers standardized on 'simple' text formats for all of their tools. Heck, even HTTP uses text even though, at the time it was created, the data rates actually made sending text files take time! It's just so much more valuable to SEE your data.

So if you're writing to a file, or reading from a file, that is a fine time to have a string that represents a more complicated object. Don't keep that string around, though. If you read a line, and you're going to need to manipulate the data it represents, it's almost always wiser to convert the entire string into an object, manipulate the object, then convert it back to a string. We can sometimes figure out what we're doing is more efficient if we leave the string alone. Those cases only present themselves after 10+ minutes of careful analysis. And they save us milliseconds per year. So they're regularly moot.

So my rule of thumb is if I have a formatted string, I want to convert it to an object ASAP. And if an object is bound for a file, I want to convert it to a String representation somehow. CSV-style is great. JSON is great. I'm getting tired of XML at this point. It takes 50 lines of code and 100 extra characters to say something in XML compared to everything else. It's all-around easier for me to read CSV and JSON. And that's why I picked text in the first place, so I could read it!