cargo-script-mvs VS Fast C++ CSV Parser

The eRFC was intentionally light on details so the Pre-RFC / IRLO thread and the demo best reflect what we hope to accomplish which are pretty detailed as-is.

> A) is easy to write one off scripts that do a job fast, with minimal thinking and effort. I am thinking of Python and Ruby. For me I can write code with high velocity in these languages.

Once I wrap up some other projects, I plan to explore this space a little bit within Rust.

imo the biggest bang for the buck is just having good `#!` support. Probably mid-year I expect to have a Pre-RFC up for single-file cargo packages. See https://github.com/epage/cargo-script-mvs/discussions/15.

A bigger effort is a batteries included, non-zero cost stdlib. I've started writing up my thoughts at https://github.com/ergo-rs/ergo.

For more background on why I think these are important, see https://epage.github.io/blog/2021/09/learning-rust/.

Would love feedback on these ideas and other ways to make Rust easy to use without sacrificing what makes Rust it is.

This is something I'm interested. Every time I write a bash or Python script, I think "why didn't I do this in Rust?". The first barrier is in the same line as your thoughts which is why I've been investigating the various cargo-script spin-offs and working towards an MVP for a Pre-RFC.

Something I've been thinking a lot about for Rust is what can and should a REPL experience be for a compiled language (ie what are reasonable compromises).

There seem to be two repls that haven't gotten much traction:

- https://github.com/google/evcxr/blob/main/evcxr_repl/README....

- https://github.com/sigmaSd/IRust

There have been little and big nits that have held me back from wanting to push these further, including

- Bad defaults (having to opt-in to panic handling)

- Command syntax feeling out of place and likely not beginner friendly

- Limits on variable preservation

- Lack of introspection (at least irust as `:type`)

So far I've been punting on wanting to improve this area by instead focusing on polishing up a rust script solution in the hopes of getting it merged: https://github.com/epage/cargo-script-mvs

rust-script is the most up-to-date version I could find. See https://github.com/epage/cargo-script-mvs/discussions/15

cargo-script has been forked or reimplemented several times.

cargo-script: I've done some initial analysis and recorded my thoughts on what cargo-script in Rust should look like. If people are interested in this or other individual / company on-boarding improvements, I'd love to talk!

Fully agree with this though I also feel there is room for experimentation and improvement in this area. I've previously blogged on this and have started researching cargo-script. Hopefully later I'll get to my standard-adjacent library.

Sorry that I still have a life. Had to analyse and mangle many large csv files and switched from Python and its csv module to: https://github.com/ben-strasser/fast-cpp-csv-parser and C++ containers/types. Python is just ineffable slow in comparison (as I wrote from >1hr to <1s).

where csv_reader is a CSVReader type from: https://github.com/ben-strasser/fast-cpp-csv-parser, we're reading iris.data, a CSV file which contains double,double,double,double,string values.

Good night everybody, I was trying to work with some csv file that had some hebrew characters, therefore I need to use std::wstring, but the ones I found didn't supported wide characters, like this one.\ Does anybody here knows any csv parser that works with wide chars? Thanks in advance.

*Go with my first instinct and do it in C++ anyways? I already use python at work and I'm wondering if a tool featuring a C++ parser as the back-end and something like pysimplegui as the front end could be a game-changer at my job.

This one comes to mind: https://github.com/ben-strasser/fast-cpp-csv-parser

I did consider the parser returning std::optional, but I think it is situational whether one would look nicer than the other. For example, using value_or() in the first example would not work since I do not want to print anything if the row is invalid, so I would still have to check the optional, and than add another line to decompose the tuple resulting in more lines. Notice that p.valid() can also be used to check if the file was open within the constructor. Fetching error messages would also be slightly more complicated. As for exceptions, I do no think it could work at all in this iteration loop since it would break the loop even if I catch it, and again, file not open would need to be handled too, and making it throw would require me to enclose the whole parser in a try/catch block since the constructor would throw that exception, one of the problems I had with the fast-cpp-csv-parser. Its all a trade-off, but I think I will stick with p.valid(), tho I will consider it still.

fast-cpp-csv-parser - 2.022 +- 0.025 [s]