val_deleplace

We agreed to make the threadsafeness more explicit in the documentation of the 'unique' package: https://github.com/golang/go/issues/69637

I tested with many concurrent goroutines, and confirmed that calling `unique.Make` does not cause any data race condition

Yes, the package is designed to be thread-safe

Mere quadratic time complexity is something I would expect to timeout and catch at fuzzing time, as long as we do encourage non-tiny inputs, say 10K and beyond.

Yes, definitely dozens of pretty good online resources. Here are 3:

- Tour of Go: https://tour.golang.org/

- Practical Go: Real world advice for writing maintainable Go programs, by Dave Cheney: https://dave.cheney.net/practical-go/presentations/gophercon...

- Uber Go Style Guide: https://github.com/uber-go/guide/blob/master/style.md

You may upvote the Swift request here: https://github.com/Deleplace/programming-idioms/issues/30

Yep! Curation is though.

It's already possible and encouraged to improve the solutions. The "edit" button shows up on computer browsers, not on mobile if the screen is small.

There's no "debate" capabilities, though.

Indeed! I updated the implementation to hoist the quadratic strlen.

I agree with the 2 example tasks, which are not "simple" to write.

The remove-by-value snippet is 8 lines, and it can be wrong in a subtle way: if list contains pointers, then we have a memory leak beyond the slice final length (pointer values still exists within capacity, and objects are not garbage collected).

I wrote several possible implementations here, none of which is as concise and as obviously correct as an hypothetical "list.remove(v)": https://programming-idioms.org/idiom/136/remove-all-occurren...

Author here: there were 2 initial use cases for me,

(1) I'm familiar with the language X but I forget e.g. how to "check if a file exists"

(2) I'm learning a new language Y, I know that "checking if a file exists" is a legit need and there must be an idiomatic way to do it in Y, so I look at the entry, alongside implementations in other languages that I'm more familiar with, so I can quickly spot the similitudes and the differences.

I do (1) all the time because my brain has very little onboard memory.

The website is open to contributions without prior validations. This means that not all snippets end up being both correct and idiomatic. I manually revert spam and "obviously incorrect" entries. For languages that I don't know very well, I encourage actual experts to fix snippets, or add a better new implementation, when they see poor contents.

You can vote for Swift here https://github.com/Deleplace/programming-idioms/issues/30

See https://github.com/divan/txqr for this use case. Other probably exist. It can be useful sometimes to not bother with any network at all, e.g. an international museum machine streaming map and documentation for tourists.

This submission being popular in HN caused an interesting traffic spike in Programming Idioms. Here is a detailed recital of the technical and financial consequences: https://medium.com/google-cloud/surviving-traffic-spike-from...

This draft: https://github.com/dgryski/go-perfbook/blob/master/TODO This short list: https://github.com/enocom/gopher-reading-list#performance This article: https://medium.com/@val_deleplace/go-code-refactoring-the-23...

Hi iainmerrick, just for info the measured per-file cost didn't include reading from the filesystem. Only the in-memory parsing was taken into account.

scott_s you're totally right on both points.

FWIW I really mean the "take the numbers with a grain of salt" advice, i.e. "Your mileage may vary". What I'm sharing in this article is not a bunch of hard, strong, exact numbers ; It's a journey and an invitation to apply similar reasoning process to your own use case and hardware.

Hi jerf, please note that

- the benchmark was designed to repeatedly parse an in-memory byte slice (not the hard drive), thus IO contention is unlikely here ;

- concurrency is a big win when IO is a bottleneck : keep processing dozens of things while some of them are waiting for data from network or hdd.