Add links to alternatives to the readme

[mcabbott]

trafficstars

As discussed here https://discourse.julialang.org/t/how-do-i-know-if-a-package-is-good/82133, it might be nice if this package linked to alternative ways to read CSV files. Really all packages should do this, but this one is what you find if you google "csv julia"... and I bet that many people googling that just want DelimitedFiles.

I'm not really qualified to write the list of fancier alternatives, since DelimitedFiles does what I need right now. But @juliohm @sl-solution @chriselrod from discourse thread may have better ideas. And in particular about what most important differences should be mentioned.

I'm especially unqualified to list Python or R alternatives. That's less obviously necessary, but their names are terms people might search for.

Xref https://github.com/JuliaPy/Pandas.jl/issues/87 about Pandas.jl -> DataFrames.jl.

[quinnj]

Yeah..........this is mostly fine. I'm hopeful that by the CSV.jl 1.0 release, we can get the time-to-first-read to be really competitive with DelimitedFiles.jl and then I don't think there's really any reason to use it.

DLMReader.jl is a great reference because it supports some more exotic parsing configurations if you need to get really custom.

I'd prefer we remove the reference to CSVFiles.jl/TextParse.jl; they haven't been updated or had any real work done for a long time, and they don't provide any kind of functionality not supported in CSV.jl.

[mcabbott]

really competitive with DelimitedFiles.jl and then I don't think there's really any reason to use it

Unless you want a matrix not a dataframe, right? There is a place for loading/saving 10 numbers without figuring out any complicated types.

prefer we remove the reference to CSVFiles.jl/TextParse.jl; they haven't been updated

I guess my vote is to then say roughly that. It's useful information if you are trying to figure out how all these packages relate to each other. Otherwise you have to try to infer from the dates... is X not mentioned by Y because it's the newer nice thing which didn't exist when Y's summary was written, or because it's the older attempt at the same which is no longer needed, or just because the authors of X and Y don't get along?

[quinnj]

Yeah, that's fair. I'm fine adding that text then.

[davidanthoff]

I'd prefer we remove the reference to CSVFiles.jl/TextParse.jl; they haven't been updated or had any real work done for a long time, and they don't provide any kind of functionality not supported in CSV.jl.

I'm fine either way, but it is probably worth pointing out that this set of packages works well and for some applications not having updates frequently is a huge plus. We are using these packages in my research group extensively, because they work just fine, and not having to deal with updates is a plus for many of our use-cases. And neither package is deprecated.