News for hackers. Stuff that matters.

val_deleplace

Re:Interning in Go on Friday September 27, 2024 @07:27PM (#41676533)
We agreed to make the threadsafeness more explicit in the documentation of the 'unique' package: https://github.com/golang/go/issues/69637
Re:Interning in Go on Thursday September 19, 2024 @12:15PM (#41593401)
I tested with many concurrent goroutines, and confirmed that calling `unique.Make` does not cause any data race condition
Re:Interning in Go on Thursday September 19, 2024 @11:39AM (#41593026)
Yes, the package is designed to be thread-safe
Re:Go Fuzzing on Sunday January 02, 2022 @09:52AM (#29769144)
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.
Re:Effective Go on Sunday October 03, 2021 @05:32AM (#28735767)
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

Re:Programming Idioms on Monday August 16, 2021 @07:57AM (#28197070)
You may upvote the Swift request here: https://github.com/Deleplace/programming-idioms/issues/30
Re:Programming Idioms on Monday August 16, 2021 @07:53AM (#28197041)
Yep! Curation is though.
Re:Programming Idioms on Monday August 16, 2021 @06:36AM (#28196647)
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.

Re:Programming Idioms on Monday August 16, 2021 @06:33AM (#28196632)
Indeed! I updated the implementation to hoist the quadratic strlen.
Re:Go is not an easy language on Monday February 22, 2021 @06:20AM (#26223240)
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...

Re:Programming Idioms on Wednesday April 29, 2020 @06:04AM (#23017407)
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.

Re:Programming Idioms on Wednesday April 29, 2020 @05:53AM (#23017341)
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.
Re:Programming Idioms on Wednesday October 09, 2019 @09:46AM (#21203127)
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...
Re:Go code refactoring: the 23x performance hunt on Monday June 18, 2018 @09:31AM (#17338069)
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.
Re:Go code refactoring: the 23x performance hunt on Monday June 11, 2018 @04:22PM (#17288197)
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.

Re:Go code refactoring: the 23x performance hunt on Monday June 11, 2018 @04:13PM (#17288102)
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.