I'd like to review your README

Re:I'd like to review your README by rendaw on Saturday April 17, 2021 @07:00AM (#26843288)

I'd expect a fast json parser to be harder to use than an easy-to-use or simple one. But if I need to eke out maximum performance on something I'm going to skip the ones that don't have fast in the description - it means the project's goals aren't aligned with my use case. If it's a web project then I'm going to focus on parsers that have have actually considered security over the ones that haven't.

These are all important words for describing projects.

[ Parent | on HN ]

Re:I'd like to review your README by johnchristopher on Saturday April 17, 2021 @07:38AM (#26843482)

Fast is not a KPI though. It can and is often labeled on anything, making the term useless even when fast is a criteria over ease of us.

Maybe something at the top along the lines of : what it does, how and then what are the implications.

[ Parent | on HN ]

Re:I'd like to review your README by mikepurvis on Saturday April 17, 2021 @11:41AM (#26845063)

Claiming "fast" implies that performance is a project goal, possibly even tracked over time as a metric, and that there's probably a comparison deeper in the README or elsewhere. It probably also means that when it comes to tradeoffs (compile time, code size, binary size, ergonomics, maybe even strictness/correctness), runtime speed is the preferred option.

[ Parent | on HN ]

Re:I'd like to review your README by jeddy3 on Sunday April 18, 2021 @03:43AM (#26850604)

"[description], aimed at speed" or something like that is better in that case, IMHO.

[ Parent | on HN ]

Re:I'd like to review your README by s3ker on Saturday April 17, 2021 @07:16AM (#26843377)

You forgot to add military-grade encryption and cloud-native tags

[ Parent | on HN ]