|
Be careful about the logic of setting shiny if it's nil. If you have two threads enter that function at the same time (e.g., if the struct is being read and therefore shiny is being initialized once by two different go-routines) you can end up with two different values of shiny, as if both check if shiny is nil at the same time they'll both go on to randomly generate a value. A constructor will help to prevent this as you're less likely to accidentally use a constructor in this way, but another solution (if the constructor ends up being un-ergonomic and you want to stay lazy) is the neat sync.Once mutex, which I think is fairly idiomatic. Just set it inside the sync.Once.Do, and then read it directly in the getter. No comparing to nil needed so it works for non-pointer values. This is safe "Because no call to Do returns until the one call to f returns". Either way, n-thing what the other posters have said, make sure your source of randomness is injectable otherwise testing is going to be annoying.
|
# ¿ Sep 6, 2021 00:31 |
|
|
# ¿ May 5, 2024 13:10 |
|
It’s still ‘curl | bash’ if the fetch command is ‘git’ and you compile and exec the binary yourself. Unless you deeply inspect the source code you’re just replacing a pipe with the file system. I’m a little salty about this because it’s a difficult sell to package internal tools to engineers with “curl | sh” (from a trusted URL and verifiable source!) but nobody really thinks about their normal dependancy process with the same skepticism. I don’t quite understand it!
|
# ¿ Aug 31, 2023 14:20 |
|
I write a bit of cgo every now and I sometimes get annoyed by how they’ve made it very difficult to add stuff to the CFLAG headers. However, the reasoning as to why they did it is solid - less chances for arbitrary code execution where you wouldn’t expect it. Anybody who has experienced a NPM package going rogue for political reasons would hopefully sympathise with Go keeping a very tight lid on “neat” dependency manager features.
|
# ¿ Sep 1, 2023 12:53 |