> just "require 'csv'". No gems required.

Seven years ago, at the time I was starting the job I mentioned, this was not a thing. The gem was called 'fastercsv' and it was made a standard library in 1.9 – we were mostly working on 1.8.7 when I started, and 1.9.2 when I did the CSV implementation(s). It was a brand new standard library and it did not do all things for all people. Almost like they just picked a pretty good one off the shelf!

It still does not do all things for all people... today, you also have other competing implementations, say 'smartercsv' with most recent commit activity 4 days ago.

It's an implementation of CSV. If you know your CSV is pristine, you can parse it in a lot less than 700 lines. We had a utility that would output "pristine CSV" dumped out from whatever garbage the client sent us, in whatever Excel or other columnular format, and we had another utility that would only accept this "pristine" format. Sometimes things went wrong. More often than you expect maybe, and we'd fix them ... or sometimes we'd get the clients to fix their shitty files, and leave it the way we thought it should work.

Depending on what you need to do with the CSV, or how many ways you're planning on handling CSV, one could argue that you will be better served by a minimal implementation that you know exactly what it does and does not do, because you told it what to do. If it's making a mistake, that's yours. You own it! That's another boon, when the quality of the data is not guaranteed.

The standard library I remember has some great idiosyncrasies that you'll know if you've ever used it to work on bad CSV. So do all of the CSV libraries. I don't work on CSV anymore and my memory of it is not so good, so I can't tell you the war stories in perfect detail, but... suffice it to say there are several CSV libraries with different strengths and weaknesses.

We mixed and matched parts that served the specific need we had at any given time and place, until I was a total CSV expert. It was not a perfect ecosystem, and 7 years ago `require 'csv'` was simply not a thing. You had to pick one off the shelf, or roll your own. I'm really not sure what's different today. (Probably not much! Parsing CSV is not a core competency of either Ruby core team, or Rails.) We had our reasons though, to be sure.

The one I remember in particular was a bit that converted your CSV rows and columns and then turned them into arrays of hashes, or converted arrays of hashes into CSV, and then another piece that expected the hashes to be identically ordered. If you used all of the standard pieces, this worked great! I think it took multiple libraries to do this, actually, and some of them were not so standard.

But wait... hash keys are not ordered at all, and that's a property of hashes that is standard and well known. But in some cases the hashes do come back with their keys in a particular, consistent order, and in a perfect walled-garden use of the particular CSV library configuration that was expected by the people that wrote this crap, yeah everything worked.

Well, everything worked until you do get a CSV with an uneven number of columns in some of the rows.

Like I said, CSV was supposed to be a core competency for us. We would not have been successful if we just picked one CSV library and stuck with it. Or, that CSV library would have got a lot of free labor from us, I'm not really sure which. I'm not sure which is worse, either. I don't do that anymore though.