mattewong

4 ms·

1.
by mattewong 10mo ago
The site says privacy-first and also says "we cannot lose your data if we never collect it" but it makes a WHOLE lot of POST calls passing what appear to be encrypted payloads, and refuses to work offline-- so the user has no way
2.
by mattewong 10mo ago
What is the advantage of this over the parser used by xsv? From the documentation, the only difference I can see is that xsv handles weird CSV better than this crate-- which in some situations is very important! So presumably this one must
3.
by mattewong 10mo ago
Looks interesting and I gave it a whirl-- thank you. Your intro mentions filter + sort, but I couldn't find a way to do that in the web UI (maybe that's just my ineptitude). Re your question whether it would be useful: hard to ans
4.
by mattewong 11mo ago
Hi HN, I'm the author of zsv. zsv was built because I needed a library to integrate with my application, and other CSV parsers had one or more of a variety of limitations (couldn't handle "real-world" CSV or malformed UT
5.
Show HN: ZSV – A fast, SIMD-based CSV parser and CLI toolkit(github.com)
1 points by mattewong 11mo ago|1 comments
6.
by mattewong 11mo ago
> even if it's "this isn't useful because X." OK... this isn't useful to me because I now just only use mermaid and stopped using other diagraming tools, because mermaid can be embedded now in so many places (git
7.
by mattewong 11mo ago
Maybe better if the website discloses the fact that file names are getting tracked via POST to the server
8.
by mattewong 11mo ago
< Technical details about the data wrangling happy to share in comments if anyone's interested in that nightmare. I'm interested. That is the nightmare my company obsesses about solving
9.
by mattewong 2y ago
Your follow-up post is helpful and appreciated! Re the original analysis, my own opinion is that the outcome is only surprising when the critical detail, highlighting how the two are different, is omitted. It seems very unsurprising if it i
10.
by mattewong 2y ago
That is great, thank you. I'd love to continue the conversation-- maybe easier in a separate forum. Can I follow-up via the email address on your profile (gaven...)?
11.
by mattewong 2y ago
Glad to be helpful-- I'm in the business of data process automation, so I appreciate the opportunity to learn about new use cases. If you are willing to share what your end goal was in more detail (even as simple as an SQL query that y
12.
by mattewong 2y ago
This is misleading. First, as other comments have noted, it is comparing multi-threaded/parallelized vs single-threaded, and its total CPU time is much longer than wc's. Second, it suggests there is something special going on, whe
13.
by mattewong 2y ago
I am always a proponent of starting with the end goal and then working backward. What are the end results you are aiming to achieve (or aiming to allow your audience to achieve)? Is marginal precision more important than the speed impact? T
14.
by mattewong 2y ago
Haven't yet seen any of these beat https://github.com/liquidaty/zsv (of which I'm an author) when real-world constraints are applied (e.g. we no longer assume that line ends are always \n, or that there are n
15.
by mattewong 2y ago
I cannot imagine any way it is worth anyone's time to follow this article's suggestion vs just using something like zsv ( https://github.com/liquidaty/zsv , which I'm an author of) or xsv ( https:/&#x
16.
by mattewong 2y ago
so true. sometimes the best solutions are not sexy
17.
by mattewong 3y ago
While you're making a CSV variant, why not go the extra step and remove the single most problematic CSV performance problem and make NSV compatible with high-performance, parallelized processing by eliminating quoting, and instead use
18.
Show HN: JSON writer: small, fast, versatile and permissively-licensed(github.com)
2 points by mattewong 3y ago|0 comments
19.
Show HN: An ultra-lightweight application auto-updater(github.com)
2 points by mattewong 3y ago|0 comments
20.
The mythical single source of truth(counting.substack.com)
1 points by mattewong 3y ago|0 comments
21.
by mattewong 3y ago
Do you have revenue? If not, how close to revenue are you?
22.
Why is paid social media a bad idea?(world.hey.com)
5 points by mattewong 3y ago|0 comments
23.
Financial Institution Innovation Needed in Silicon Valley(clsbluesky.law.columbia.edu)
2 points by mattewong 3y ago|0 comments
24.
by mattewong 4y ago
If it could be tabular in nature, maybe convert to sqlite3 so you can make use of indexing, or CSV to make use of high-performance tools like xsv or zsv (the latter of which I'm an author). https://github.com/liquidaty&
25.
by mattewong 4y ago
csvkit and miller are both extraordinarily slow try xsv ( https://github.com/BurntSushi/xsv ) or zsv ( https://github.com/liquidaty/zsv ) instead (the latter of which I'm an author of)
26.
by mattewong 4y ago
Yes, that is exactly my point. You cannot start threads at 0/25/50/75 if your data is in CSV format. But what I am saying is that, if you could do that , then your performance difference will be negligible, compared to using
27.
by mattewong 4y ago
Good point. Though, if we are talking about something coming down a network pipe, then that network connection will be serialized anyway and during the parsing process can be sharded or converted to another format or indexed or whatnot. I w
28.
by mattewong 4y ago
Parsing CSV doesn't have to be slow if you use something like xsv or zsv ( https://github.com/liquidaty/zsv ) (disclaimer: I'm an author). The speed of CSV parsers is fast enough that unless you are doing somet
29.
Ask HN: Does a website's server-side WASM = “distribution” for license purposes?
1 points by mattewong 4y ago|0 comments
30.
by mattewong 4y ago
Another for the mix: https://github.com/liquidaty/zsv

More ›