15 ms·

A love letter to the CSV format (2024)

109 points by jordigh 1y ago

ayhanfuat 1y ago
Previously: A love letter to the CSV format (https://github.com/medialab/xan/blob/master/docs/LOVE_LETTER.md https://github.com/medialab/xan/blob/master/docs/LOVE_LETTER...) 708 points | 5 months ago | 698 comments (https://news.ycombinator.com/item?id=43484382 https://news.ycombinator.com/item?id=43484382)
klinch 1y ago
Hot take: I prefer xlsx over CSV I used to work on payment infrastructure and whenever a vendor offered us the choice between CSV and some other format we always opted for that other format (often xlsx). This sounds a bit weird, but when using xlsx and a good library for handling it, you never have to worry about encoding, escaping and number formatting. This is one of these things that sound absolutely wrong from an engineering standpoint (xlsx is abhorrently complex on the inside), but works robustly in practice. Slightly related: This was a German company, with EU and US payment providers. Also note that Microsoft Excel (and therefore a lot of other tools) produces "semicolon-separated values" files when started on a computer with the locale set to German...
- n4r9 1y ago
  Works okay until someone opens the file in Excel, writes "2-9" into a cell, and saves it without realising it's been changed to "02/09/2025" behind the scenes.
  - chungy 1y ago
    Wait until you find out that "02/09/2025" is actually 45697 behind the scenes ;)
    - cluckindan 1y ago
      And thus, with some semantic leeway, -7 = 45697
    - porridgeraisin 1y ago
      Why?
- personalityson 1y ago
  It should have been semicolon from the start
  - IanCal 1y ago
    There's ascii characters for field and record delimiters which would be perfect. I tried using them once after what felt like an aeon of quoting issues, and the first customer file I had had them randomly appearing in their fields.
- olive-n 1y ago
  I'll take csv over xlsx any time. I work a lot with time series data, and excel does not support datetimes with timezones, so I have to figure out the timezone every time to align with other sources of data. Reading and writing them is much slower than csv, which is annoying when datasets get larger. And most importantly, xlsx are way more often fucked up in some way than any other format. Usually, because somebody manually did something to them and sometimes because the library used to write them had some hiccup. So I guess a hot take indeed.
- imtringued 1y ago
  This is the correct take. I've never had any significant problems with xlsx. You may call it abhorrently complex, but for me it is just a standardized way to serialize tabular data via XML.
- porker 1y ago
  > when using xlsx and a good library for handling it Which good libraries did you find? That's been my pain point when dealing with xlsx.
  - klinch 1y ago
    Apache POI (Java) + a light in-house abstraction on top of it
hiAndrewQuinn 1y ago
I like CSV because its simplicity and ubiquity make it an easy Schelling point in the wide world of corporate communication. Even very non-technical people can, with some effort, figure out how to save a CSV from Excel, and figure out how to open a CSV with Notepad if absolutely necessary. On the technical side libraries like pandas have undergone extreme selection pressure to be able to read in Excel's weird CSV choices without breaking. At that point we have the luxury of writing them out as "proper" CSV, or as a SQLite database, or as whatever else we care about. It's just a reasonable crossing-over point.
- heresie-dabord 1y ago
  CSV is a flexible solution that is as simple as possible. The next step is JSONL. https://jsonlines.org/ https://jsonlines.org/ https://medium.com/@ManueleCaddeo/understanding-jsonl-bc8922129f5b https://medium.com/@ManueleCaddeo/understanding-jsonl-bc8922...
deleted 1y ago
[deleted]
mcdonje 1y ago
>Excel hates CSV. It clearly means CSV must be doing something right. Use tabs as a delimiter and excel interops with the format as if natively.
- tacker2000 1y ago
  The problem is that nobody in the real world uses tabs. Everyone uses , or ; as delimiters and then uses either . or , for decimals, depending on the source. It shouldnt be so hard to auto-detect these different formats, but somehow in 2025, Excel still cannot do it.
  - sfn42 1y ago
    You don't need to auto-detect the format. The delimiter can be declared at the top of the file as for example sep=;
    - yrro 1y ago
      But now that's not CSV. It's CSV with some kind of ad-hoc header...
      - sfn42 1y ago
        It may not be part of any official CSV spec but Excel accepts it. I found that Excel would read my files much more reliably using the sep declaration, which is great when the target audience is less technical types.
    - IAmBroom 1y ago
      I love you forever and a day. Thank you.
      - sfn42 1y ago
        Happy to help! :)
    - tacker2000 1y ago
vim-guru 1y ago
Excel hates CSV It clearly means CSV must be doing something right.
- wkat4242 1y ago
  Especially in Europe because we use the comma as a decimal point. So every csv file opened in Excel is screwed up.
  - adithyassekhar 1y ago
    Someone should write an article on this
guzik 1y ago
I am glad that we decided to pick CSV as our default format for health data (even for heavy stuff like raw ECG). Yeah, files were bigger, but clients loved that they could just download them, open in Excel, make a quick chart. Meanwhile other software was insisting on EDF (lighter, sure) but not everything could handle it.
- IAmBroom 1y ago
  And at this point, "lighter" is immaterial. "Hi, I'm sending you a two-line statement in a Word document. It's 10kB." "Thanks, I took a screenshot of it and forwarded it. It's now 10MB." "Great! That's handy!"
untrimmed 1y ago
This is a great defense, but I feel like it misses the single biggest reason CSV will never die: your boss can open it. We can talk about streaming and Parquet all day, but if the marketing team can't double-click the file, it's useless.
- imtringued 1y ago
  With what software? LibreOffice? Excel doesn't support opening CSV files with a double click. It lets you import CSV files into a spreadsheet, but that requires reading unreasonably complicated instructions.
  - jowea 1y ago
    How is that not opening?
    - imtringued 1y ago
      You are creating a new spreadsheet that you can save as an xlsx. What you are looking at is not the CSV file itself.
      - NoboruWataya 1y ago
        This is a distinction that does not matter to most non-technical people.
      - tokai 1y ago
        You are missing the point so hard its hilarious.
      - john_the_writer 1y ago
        Well I mean unless you're inspecting it with a hex editor, you're not looking at the csv file itself. Even then, I suppose you could say that's not even the file itself. An electron microscope perhaps? But then you've got the whole Heisenberg issue, so there's that.
      - 1y ago
femto 1y ago
CSV is good for debugging C/C++ real-time signal processing data paths. Add cout or printf lines, which on each iteration print out relevant intermediate values separated by commas, with the first cell being a constant tag. Provided you don't overdo it, the software will typically still run in real-time. Pipe stdout to a file. After the fact, you can then use grep to filter tags to select which intermediate results you want to analyse. This filtered data can be loaded into a spreadsheet, or read into a higher level script for analysis/debugging/plotting/... In this way you can reproducibly visualise internal operation over a long period of time and see infrequent or subtle deviations from expected behaviour.
- matt_daemon 1y ago
  Agree this is the main use for it
joz1-k 1y ago
Except that the "comma" was a poor choice for a separator, the CSV is just a plain text that can be trivially parsed from any language or platform. That's its biggest value. There is essentially no format, library, or platform lock-in. JSON comes close to this level of openness and ease, but YAML is already too complicated as a file format.
- jstanley 1y ago
  JSON has the major annoyance that grep doesn't work well on it. You need tooling to work with JSON.
  - theknarf 1y ago
    grep is a tool. jq is a good tool for json.
    - kergonath 1y ago
      grep is POSIX and you can count on it being installed pretty much anywhere. That’s not the case for jq.
      - whizzter 1y ago
        Do people contain themselvs to a POSIX conformant grep subset in practice, or do you mean GNU grep that probably doesn't behave according to spec unless POSIXLY_CORRECT is set?
      - IAmBroom 1y ago
        "Anywhere" does not include Windows environments, which are over half the work computers out there.
        deleted 1y ago
        [deleted]
        krogenx 1y ago
IanCal 1y ago
Counterpoint - CSV is absolutely atrocious and should be cast into the Sun. It's unkillable, like many eldritch horrors. > The specification of CSV holds in its title: "comma separated values". Okay, it's a lie, but still, the specification holds in a tweet and can be explained to anybody in seconds: commas separate values, new lines separate rows. Now quote values containing commas and line breaks, double your quotes, and that's it. This is so simple you might even invent it yourself without knowing it already exists while learning how to program. Except that's just one way people do it. It's not universal and so you cannot take arbitrary CSV files in and parse them like this. You can't take a CSV file constructed like this and pass it into any CSV accepting program - many will totally break. > Of course it does not mean you should not use a dedicated CSV parser/writer because you will mess something up. Yes, implementers often have. > No one owns CSV. It has no real specification Yep. So all these monstrosities in the real world are all... maybe valid? Lots of totally broken CSV files can be parsed as CSV but the result is wrong. Sometimes subtly. > This means, by extension, that it can both be read and edited by humans directly, somehow. One of the very common ways they get completely fucked up, yes. Someone goes and sorts some rows and boom broken, often unrecoverable data loss. Someone doesn't correctly add or remove a comma. Someone mixes two files that actually have differently encoded text. > CSV can be read row by row very easily without requiring more memory than what is needed to fit a single row. CSV must be parsed row by row. > By comparison, column-oriented data formats such as parquet are not able to stream files row by row without requiring you to jump here and there in the file or to buffer the memory cleverly so you don't tank read performance. Sort of? Yes if you're building your own parser but who is doing that? It's also not hard with things like parquet. > But of course, CSV is terrible if you are only interested in specific columns because you will indeed need to read all of a row only to access the part you are interested in. Or if you're interested in a specific row, because you're going to have to be careful about parsing out every row until you get there. CSV does not have a row separator. Or rather it does but it also lets you have that row separator appear and not mean "separate these rows" so you can't simply trust it. > But critics of CSV coming from this set of pratices tend to only care about use-cases where everything is expected to fit into memory. Parquet uses row groups which means you can stream chunks easily, those chunks contain metadata so you can easily filter rows you don't need too. I much more often need to keep the whole thing in memory working with CSV than parquet. With parquet I don't even need to be able to fit all the rows on disk I can read the chunk I want remotely. > CSV can be appended to Yeah that's easier. Row groups means you can still do this though, but granted it's not as easy. *However* I will point out that absolutely nothing stops someone completely borking things by appending something that's not exactly the right format. > CSV is dynamically typed Not really. Everything is strings. You can do that with anything else if you want to. JSON can have numbers of any size if you just store them as strings. > CSV is succinct Yes, more so than jsonl, but not really more than (you guessed it) parquet. Also it's horrific for compression. > Reverse CSV is still valid CSV Get a file format that doesn't absolutely suck and you can parse things in reverse if you want. More usefully you can parse just sections you actually care about! > Excel hates CSV Helpfully this just means that the most popular way of working with tabular data in the world doesn't play that nicely with it.
efitz 1y ago
I don’t think I ever heard anyone say “csv is dead”. Smart people (that have been burned once too many times) put quotes around fields in csv if they aren’t 100% positive the field will be comma-free, and escape quotes in such fields.
eviks 1y ago
> Okay, it's a lie, Indeed, a lie only a lover would believe,,,
xbmcuser 1y ago
I did not care for CSV format much till I started using them with llm and python scripts.
jcattle 1y ago
If you don't care that much about the accuracy of your data (like only caring about a few decimals of accuracy in your floats), you don't generate huge amounts of data, you do not need to work with it across different tools and pass it back and forth, then yes CSV CAN be nice. I wouldn't write it a love letter though. There's a reason that parquet exists.
- christophilus 1y ago
  CSV is just a string serialization, so you can represent floats with any accuracy you choose. It’s streamable and compressible, so large files are fine, though maybe not “huge” depending on how you define “huge”. It works fine passing back and forth between various tools, so… Without more specifics, I disagree with your take.
  - jcattle 1y ago
    It's only fine passing between various tools if you tell each tool exactly how they should serialize your values. Each tool will interpret column values in some way and if you want to work with those values in any meaningful way it will convert to their representation of the data type that is likely present in a column. Going from tool to tool will leave you with widely different representations of the original data you've put in. Because as you said yourself. All of this data does not have any meaning. It's just strings. The csv and the tools do not care if one column was ms-epoch and another was mathematical notation floating point. It'll all just go through that specific tools deserialization - serialization mangle and you'll have completely different data on the other end.
    - bsghirt 1y ago
      How would you deserialise the entity "0.4288"?
lan321 1y ago
I hate parsing CSV. There are so many different implementations it's a constant cat and mouse.. Literally any symbol can be the separator, then the ordering starts getting changed, then since you have to guess what's where you go by type but strings, for example, are sometimes in quotations, other times not, then you have some decimal split with a comma when the values are also separated with commas so you have to track what's a split and what's a decimal comma.. Then you get some line with only 2 elements when you expect 7 and have no clue what to do because there's no documentation for the output and hence what that line means.. If the CSV is not written by me it's always been an exercise in making things as difficult as possible. It might be a tad smaller as a format but I find the parsing to be so ass you need really good reason to use it. Edit: Oh yeah, and some have a header, others don't and CSV seems to always come from some machine where the techs can come over to do an update, and just reorder everything because fuck your parsing and then you either get lucky and the parser dies, or since you don't really have much info the types just align and you start saving garbage data to your database until a domain expert notices something isn't quite right so you have to find when was the last time someone touched the machines and rollback/reparse everything..
roland35 1y ago
To people saying that "your boss can open it" being an benefit of csv, well I have a funny story! Back in the early 2000s I designed and built a custom data collector for a air force project. It saved data at 100 Hz on an SD card. The project manager loved it! He could pop the SD card out or use the handy USB mass storage mode to grab the csv files. The only problem... Why did the data cut off after about 10 minutes?? I couldn't see the actual data collected since it was secret, but I had no issue on my end, assuming there was space on the card and battery life was good. Turns out, I learned he was using excel 2003 to open the csv file. There is a 65,536 row limit (does that number look familiar?). That took a while to figure out!!
- Dilettante_ 1y ago
  "Plz fix. No look! Just fix!!"[1] must be one of the circles of programmer hell. [1]https://i.kym-cdn.com/entries/icons/facebook/000/027/691/tumblr_nroanfy2v71qjobhbo1_1280.jpg https://i.kym-cdn.com/entries/icons/facebook/000/027/691/tum...
- IanCal 1y ago
  Love it. The first data release I did excel couldn't open the CSV file, because it started with a capital I (first column ID). Excel looks at this, looks at this file with a comma in the header and text and the ending "csv" and says I KNOW WHAT THIS IS THIS IS A SYLK FILE BECAUSE IT STARTS WITH "I" NO OTHER POSSIBLE FILE COULD START WITH THE LETTER "I" then reads some more and says THIS SYLK FILE LOOKS WRONG IT MUST BE BROKEN ERROR https://en.wikipedia.org/wiki/Symbolic_Link_(SYLK) https://en.wikipedia.org/wiki/Symbolic_Link_(SYLK)
  - IAmBroom 1y ago
    Yes! That was the STUPIDEST file encoding detection ever developed! OMG....
1vuio0pswjnm7 1y ago
Certainly I love CSV, too and agree with most of the reasons put forth in the blog post But I tried the group's "CSV magician" program and was not impressed https://github.com/medialab/xan https://github.com/medialab/xan The table output seems very similar to sqlite3 It's a 20MB musl dynamically-linked executable (cf. 1.7MB statically-linked sqlite3 executable) Most of the "suite" of subcommands seemed to be aimed at accomplishing the same stuff I can do with sqlite3, and, if necessary, flex There seemed no obvious way too disable color The last straw was it messed up the console First freezing it and the pid was not visible with ps so I had to kill the shell Then leaving me with no up/down or tab action Yes I can fix this but I should not have to I really want to keep an open mind and to believe in these rust console programs But every time I try one it is a huge executable, an assault of superfluous color and generally no functionality that cannot be achieved with existing non-rust software Even assuming I could get used to the annoying design, I like software that is reliable Compared to the software I normally use, I cannot say these rust programs are equally as reliable I also like software where I can easily edit the source to change what I do not like These rust programs would require more resources and time to compile, messing around with a package manager and heaps of dependencies, plus a new language, with no clear benefit... b/c TBH I am not losing any sleep worrying that the small text processing programs I use are written in C; after all, the operating systems I use are written in C and that is not changing anytime soon

109 points by jordigh 1y ago

Previously: A love letter to the CSV format (https://github.com/medialab/xan/blob/master/docs/LOVE_LETTER.md https://github.com/medialab/xan/blob/master/docs/LOVE_LETTER...) 708 points | 5 months ago | 698 comments (https://news.ycombinator.com/item?id=43484382 https://news.ycombinator.com/item?id=43484382)

klinch 1y ago

Hot take: I prefer xlsx over CSV I used to work on payment infrastructure and whenever a vendor offered us the choice between CSV and some other format we always opted for that other format (often xlsx). This sounds a bit weird, but when using xlsx and a good library for handling it, you never have to worry about encoding, escaping and number formatting. This is one of these things that sound absolutely wrong from an engineering standpoint (xlsx is abhorrently complex on the inside), but works robustly in practice. Slightly related: This was a German company, with EU and US payment providers. Also note that Microsoft Excel (and therefore a lot of other tools) produces "semicolon-separated values" files when started on a computer with the locale set to German...

n4r9 1y ago
Works okay until someone opens the file in Excel, writes "2-9" into a cell, and saves it without realising it's been changed to "02/09/2025" behind the scenes.
- chungy 1y ago
  Wait until you find out that "02/09/2025" is actually 45697 behind the scenes ;)
  - cluckindan 1y ago
    And thus, with some semantic leeway, -7 = 45697
  - porridgeraisin 1y ago
    Why?
personalityson 1y ago
It should have been semicolon from the start
- IanCal 1y ago
  There's ascii characters for field and record delimiters which would be perfect. I tried using them once after what felt like an aeon of quoting issues, and the first customer file I had had them randomly appearing in their fields.
olive-n 1y ago
I'll take csv over xlsx any time. I work a lot with time series data, and excel does not support datetimes with timezones, so I have to figure out the timezone every time to align with other sources of data. Reading and writing them is much slower than csv, which is annoying when datasets get larger. And most importantly, xlsx are way more often fucked up in some way than any other format. Usually, because somebody manually did something to them and sometimes because the library used to write them had some hiccup. So I guess a hot take indeed.
imtringued 1y ago
This is the correct take. I've never had any significant problems with xlsx. You may call it abhorrently complex, but for me it is just a standardized way to serialize tabular data via XML.
porker 1y ago
> when using xlsx and a good library for handling it Which good libraries did you find? That's been my pain point when dealing with xlsx.
- klinch 1y ago
  Apache POI (Java) + a light in-house abstraction on top of it

hiAndrewQuinn 1y ago

I like CSV because its simplicity and ubiquity make it an easy Schelling point in the wide world of corporate communication. Even very non-technical people can, with some effort, figure out how to save a CSV from Excel, and figure out how to open a CSV with Notepad if absolutely necessary. On the technical side libraries like pandas have undergone extreme selection pressure to be able to read in Excel's weird CSV choices without breaking. At that point we have the luxury of writing them out as "proper" CSV, or as a SQLite database, or as whatever else we care about. It's just a reasonable crossing-over point.

heresie-dabord 1y ago
CSV is a flexible solution that is as simple as possible. The next step is JSONL. https://jsonlines.org/ https://jsonlines.org/ https://medium.com/@ManueleCaddeo/understanding-jsonl-bc8922129f5b https://medium.com/@ManueleCaddeo/understanding-jsonl-bc8922...

deleted 1y ago

[deleted]

mcdonje 1y ago

>Excel hates CSV. It clearly means CSV must be doing something right. Use tabs as a delimiter and excel interops with the format as if natively.

tacker2000 1y ago
The problem is that nobody in the real world uses tabs. Everyone uses , or ; as delimiters and then uses either . or , for decimals, depending on the source. It shouldnt be so hard to auto-detect these different formats, but somehow in 2025, Excel still cannot do it.
- sfn42 1y ago
  You don't need to auto-detect the format. The delimiter can be declared at the top of the file as for example sep=;
  - yrro 1y ago
    But now that's not CSV. It's CSV with some kind of ad-hoc header...
    - sfn42 1y ago
      It may not be part of any official CSV spec but Excel accepts it. I found that Excel would read my files much more reliably using the sep declaration, which is great when the target audience is less technical types.
  - IAmBroom 1y ago
    I love you forever and a day. Thank you.
    - sfn42 1y ago
      Happy to help! :)
  - tacker2000 1y ago

vim-guru 1y ago

Excel hates CSV It clearly means CSV must be doing something right.

wkat4242 1y ago
Especially in Europe because we use the comma as a decimal point. So every csv file opened in Excel is screwed up.
- adithyassekhar 1y ago
  Someone should write an article on this

guzik 1y ago

I am glad that we decided to pick CSV as our default format for health data (even for heavy stuff like raw ECG). Yeah, files were bigger, but clients loved that they could just download them, open in Excel, make a quick chart. Meanwhile other software was insisting on EDF (lighter, sure) but not everything could handle it.

IAmBroom 1y ago
And at this point, "lighter" is immaterial. "Hi, I'm sending you a two-line statement in a Word document. It's 10kB." "Thanks, I took a screenshot of it and forwarded it. It's now 10MB." "Great! That's handy!"

untrimmed 1y ago

This is a great defense, but I feel like it misses the single biggest reason CSV will never die: your boss can open it. We can talk about streaming and Parquet all day, but if the marketing team can't double-click the file, it's useless.

imtringued 1y ago
With what software? LibreOffice? Excel doesn't support opening CSV files with a double click. It lets you import CSV files into a spreadsheet, but that requires reading unreasonably complicated instructions.
- jowea 1y ago
  How is that not opening?
  - imtringued 1y ago
    You are creating a new spreadsheet that you can save as an xlsx. What you are looking at is not the CSV file itself.
    - NoboruWataya 1y ago
      This is a distinction that does not matter to most non-technical people.
    - tokai 1y ago
      You are missing the point so hard its hilarious.
    - john_the_writer 1y ago
      Well I mean unless you're inspecting it with a hex editor, you're not looking at the csv file itself. Even then, I suppose you could say that's not even the file itself. An electron microscope perhaps? But then you've got the whole Heisenberg issue, so there's that.
    - 1y ago

femto 1y ago

CSV is good for debugging C/C++ real-time signal processing data paths. Add cout or printf lines, which on each iteration print out relevant intermediate values separated by commas, with the first cell being a constant tag. Provided you don't overdo it, the software will typically still run in real-time. Pipe stdout to a file. After the fact, you can then use grep to filter tags to select which intermediate results you want to analyse. This filtered data can be loaded into a spreadsheet, or read into a higher level script for analysis/debugging/plotting/... In this way you can reproducibly visualise internal operation over a long period of time and see infrequent or subtle deviations from expected behaviour.

matt_daemon 1y ago
Agree this is the main use for it

joz1-k 1y ago

Except that the "comma" was a poor choice for a separator, the CSV is just a plain text that can be trivially parsed from any language or platform. That's its biggest value. There is essentially no format, library, or platform lock-in. JSON comes close to this level of openness and ease, but YAML is already too complicated as a file format.

jstanley 1y ago
JSON has the major annoyance that grep doesn't work well on it. You need tooling to work with JSON.
- theknarf 1y ago
  grep is a tool. jq is a good tool for json.
  - kergonath 1y ago
    grep is POSIX and you can count on it being installed pretty much anywhere. That’s not the case for jq.
    - whizzter 1y ago
      Do people contain themselvs to a POSIX conformant grep subset in practice, or do you mean GNU grep that probably doesn't behave according to spec unless POSIXLY_CORRECT is set?
    - IAmBroom 1y ago
      "Anywhere" does not include Windows environments, which are over half the work computers out there.
      - deleted 1y ago
        [deleted]
      - krogenx 1y ago

IanCal 1y ago

Counterpoint - CSV is absolutely atrocious and should be cast into the Sun. It's unkillable, like many eldritch horrors. > The specification of CSV holds in its title: "comma separated values". Okay, it's a lie, but still, the specification holds in a tweet and can be explained to anybody in seconds: commas separate values, new lines separate rows. Now quote values containing commas and line breaks, double your quotes, and that's it. This is so simple you might even invent it yourself without knowing it already exists while learning how to program. Except that's just one way people do it. It's not universal and so you cannot take arbitrary CSV files in and parse them like this. You can't take a CSV file constructed like this and pass it into any CSV accepting program - many will totally break. > Of course it does not mean you should not use a dedicated CSV parser/writer because you will mess something up. Yes, implementers often have. > No one owns CSV. It has no real specification Yep. So all these monstrosities in the real world are all... maybe valid? Lots of totally broken CSV files can be parsed as CSV but the result is wrong. Sometimes subtly. > This means, by extension, that it can both be read and edited by humans directly, somehow. One of the very common ways they get completely fucked up, yes. Someone goes and sorts some rows and boom broken, often unrecoverable data loss. Someone doesn't correctly add or remove a comma. Someone mixes two files that actually have differently encoded text. > CSV can be read row by row very easily without requiring more memory than what is needed to fit a single row. CSV must be parsed row by row. > By comparison, column-oriented data formats such as parquet are not able to stream files row by row without requiring you to jump here and there in the file or to buffer the memory cleverly so you don't tank read performance. Sort of? Yes if you're building your own parser but who is doing that? It's also not hard with things like parquet. > But of course, CSV is terrible if you are only interested in specific columns because you will indeed need to read all of a row only to access the part you are interested in. Or if you're interested in a specific row, because you're going to have to be careful about parsing out every row until you get there. CSV does not have a row separator. Or rather it does but it also lets you have that row separator appear and not mean "separate these rows" so you can't simply trust it. > But critics of CSV coming from this set of pratices tend to only care about use-cases where everything is expected to fit into memory. Parquet uses row groups which means you can stream chunks easily, those chunks contain metadata so you can easily filter rows you don't need too. I much more often need to keep the whole thing in memory working with CSV than parquet. With parquet I don't even need to be able to fit all the rows on disk I can read the chunk I want remotely. > CSV can be appended to Yeah that's easier. Row groups means you can still do this though, but granted it's not as easy. *However* I will point out that absolutely nothing stops someone completely borking things by appending something that's not exactly the right format. > CSV is dynamically typed Not really. Everything is strings. You can do that with anything else if you want to. JSON can have numbers of any size if you just store them as strings. > CSV is succinct Yes, more so than jsonl, but not really more than (you guessed it) parquet. Also it's horrific for compression. > Reverse CSV is still valid CSV Get a file format that doesn't absolutely suck and you can parse things in reverse if you want. More usefully you can parse just sections you actually care about! > Excel hates CSV Helpfully this just means that the most popular way of working with tabular data in the world doesn't play that nicely with it.

efitz 1y ago

I don’t think I ever heard anyone say “csv is dead”. Smart people (that have been burned once too many times) put quotes around fields in csv if they aren’t 100% positive the field will be comma-free, and escape quotes in such fields.

eviks 1y ago

> Okay, it's a lie, Indeed, a lie only a lover would believe,,,

xbmcuser 1y ago

I did not care for CSV format much till I started using them with llm and python scripts.

jcattle 1y ago

If you don't care that much about the accuracy of your data (like only caring about a few decimals of accuracy in your floats), you don't generate huge amounts of data, you do not need to work with it across different tools and pass it back and forth, then yes CSV CAN be nice. I wouldn't write it a love letter though. There's a reason that parquet exists.

christophilus 1y ago
CSV is just a string serialization, so you can represent floats with any accuracy you choose. It’s streamable and compressible, so large files are fine, though maybe not “huge” depending on how you define “huge”. It works fine passing back and forth between various tools, so… Without more specifics, I disagree with your take.
- jcattle 1y ago
  It's only fine passing between various tools if you tell each tool exactly how they should serialize your values. Each tool will interpret column values in some way and if you want to work with those values in any meaningful way it will convert to their representation of the data type that is likely present in a column. Going from tool to tool will leave you with widely different representations of the original data you've put in. Because as you said yourself. All of this data does not have any meaning. It's just strings. The csv and the tools do not care if one column was ms-epoch and another was mathematical notation floating point. It'll all just go through that specific tools deserialization - serialization mangle and you'll have completely different data on the other end.
  - bsghirt 1y ago
    How would you deserialise the entity "0.4288"?

lan321 1y ago

I hate parsing CSV. There are so many different implementations it's a constant cat and mouse.. Literally any symbol can be the separator, then the ordering starts getting changed, then since you have to guess what's where you go by type but strings, for example, are sometimes in quotations, other times not, then you have some decimal split with a comma when the values are also separated with commas so you have to track what's a split and what's a decimal comma.. Then you get some line with only 2 elements when you expect 7 and have no clue what to do because there's no documentation for the output and hence what that line means.. If the CSV is not written by me it's always been an exercise in making things as difficult as possible. It might be a tad smaller as a format but I find the parsing to be so ass you need really good reason to use it. Edit: Oh yeah, and some have a header, others don't and CSV seems to always come from some machine where the techs can come over to do an update, and just reorder everything because fuck your parsing and then you either get lucky and the parser dies, or since you don't really have much info the types just align and you start saving garbage data to your database until a domain expert notices something isn't quite right so you have to find when was the last time someone touched the machines and rollback/reparse everything..

roland35 1y ago

To people saying that "your boss can open it" being an benefit of csv, well I have a funny story! Back in the early 2000s I designed and built a custom data collector for a air force project. It saved data at 100 Hz on an SD card. The project manager loved it! He could pop the SD card out or use the handy USB mass storage mode to grab the csv files. The only problem... Why did the data cut off after about 10 minutes?? I couldn't see the actual data collected since it was secret, but I had no issue on my end, assuming there was space on the card and battery life was good. Turns out, I learned he was using excel 2003 to open the csv file. There is a 65,536 row limit (does that number look familiar?). That took a while to figure out!!

Dilettante_ 1y ago
"Plz fix. No look! Just fix!!"[1] must be one of the circles of programmer hell. [1]https://i.kym-cdn.com/entries/icons/facebook/000/027/691/tumblr_nroanfy2v71qjobhbo1_1280.jpg https://i.kym-cdn.com/entries/icons/facebook/000/027/691/tum...
IanCal 1y ago
Love it. The first data release I did excel couldn't open the CSV file, because it started with a capital I (first column ID). Excel looks at this, looks at this file with a comma in the header and text and the ending "csv" and says I KNOW WHAT THIS IS THIS IS A SYLK FILE BECAUSE IT STARTS WITH "I" NO OTHER POSSIBLE FILE COULD START WITH THE LETTER "I" then reads some more and says THIS SYLK FILE LOOKS WRONG IT MUST BE BROKEN ERROR https://en.wikipedia.org/wiki/Symbolic_Link_(SYLK) https://en.wikipedia.org/wiki/Symbolic_Link_(SYLK)
- IAmBroom 1y ago
  Yes! That was the STUPIDEST file encoding detection ever developed! OMG....

1vuio0pswjnm7 1y ago

Certainly I love CSV, too and agree with most of the reasons put forth in the blog post But I tried the group's "CSV magician" program and was not impressed https://github.com/medialab/xan https://github.com/medialab/xan The table output seems very similar to sqlite3 It's a 20MB musl dynamically-linked executable (cf. 1.7MB statically-linked sqlite3 executable) Most of the "suite" of subcommands seemed to be aimed at accomplishing the same stuff I can do with sqlite3, and, if necessary, flex There seemed no obvious way too disable color The last straw was it messed up the console First freezing it and the pid was not visible with ps so I had to kill the shell Then leaving me with no up/down or tab action Yes I can fix this but I should not have to I really want to keep an open mind and to believe in these rust console programs But every time I try one it is a huge executable, an assault of superfluous color and generally no functionality that cannot be achieved with existing non-rust software Even assuming I could get used to the annoying design, I like software that is reliable Compared to the software I normally use, I cannot say these rust programs are equally as reliable I also like software where I can easily edit the source to change what I do not like These rust programs would require more resources and time to compile, messing around with a package manager and heaps of dependencies, plus a new language, with no clear benefit... b/c TBH I am not losing any sleep worrying that the small text processing programs I use are written in C; after all, the operating systems I use are written in C and that is not changing anytime soon